Event for failing reconnection

[ssukienn]

Hi.

With changes based on this issue: #145 (I actually commented there but without reply) I am unable to follow reconnection count without introducing my own timer over libs retry time (plus there is possibility that if target node is unavailable, reconnect timeout will be underlying socket connection timeout, not time from lib options, what creates it more hard to do proper syncing).

I am not against making distinction between disconnect from actually connected "connection" event (new behavior) and not successful reconnection (now missing) event. But introduced changes removed the latter events from the timeline now and it is actually breaking for users who relied on this behavior.

Now my thinking about this is that if library offers the means to reconnect disrupted connection it should also offer the means to monitor this process (it might have some importance for the consumers). We had "connect" and "disconnect" (covering actual disconnect and failed reconnections). Now we have "connect" and "disconnect" (for actual failure of connecting first time or when we get the "close" from amqp) but we miss something like "reconnection-failure".

Whether there should be seperate event or not (payload changes?) is the matter of the discussion but I think there should be events informing about failed reconnections. It is just easier for the library to provide than expect from the users to mimic or approximate. I am open to create PR in free time if we would have some decision how to proceed.

Wdyt?

[jwalton]

Sorry - missed your comment on #145. But yes, a separate event for connection attempts sounds reasonable to me. How does this sound?

[jwalton]

🎉 This issue has been resolved in version 4.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀