Currently the reconnecting event argument is the time (in ms) before reconnecting. For monitoring purposes, the attempt number is arguably much more important to emit in the logs than the time. For example, if the retryStrategy is a constant delay, knowing that the next reconnect will again happen in 2000ms seems much less valuable than knowing that this is the 10th attempt.
The only way to keep track of the reconnect attempt is by maintaining state externally which is clumsy, or by handling it in the retryStrategy implementation which seems like a hack.
Currently the
reconnectingevent argument is the time (in ms) before reconnecting. For monitoring purposes, the attempt number is arguably much more important to emit in the logs than the time. For example, if theretryStrategyis a constant delay, knowing that the next reconnect will again happen in 2000ms seems much less valuable than knowing that this is the 10th attempt.The only way to keep track of the reconnect attempt is by maintaining state externally which is clumsy, or by handling it in the
retryStrategyimplementation which seems like a hack.Passing it as the second argument would work