cody-greene / node-rabbitmq-client

RabbitMQ (0-9-1) client library with auto-reconnect & zero dependencies
MIT License
130 stars 9 forks source link

Transient vs. Permanent problems #16

Closed tttp closed 1 year ago

tttp commented 1 year ago

I'm moving a project from amqplib and I am enjoying node-rabbitmq-client very much so far, thank you for your work!

I'm not sure issue are the right place to discuss, please point me to a better venue if there is a mailing list/forum/something I missed and please indulge my rambling below.

One general issue we are trying to get right is how to distinguish between self healing issues (say network is down for 2 min, be sure we recreate the channel and keep exchanging messages as nothing happened and be confident we didn't loose any) and those that needs manual intervention (no connection for 4 hours, someone needs to check if the DNS record is correct or something)

Of course, some of it will need to be handled on the software using your library, but I'm trying to identify what signals are available that already exists to make it more robust.

connection

channel

I'm not sure if there are cases where the connection is up but channel down, is there?

consumer/producer/queue

the queue seems mostly abstracted under consumer or producer (no top class) https://cody-greene.github.io/node-rabbitmq-client

It might be already handled by the .on('error'), but I didn't find a documentation on what type of errors each object can send and what they mean.

cody-greene commented 1 year ago

is there a way to alerted that the connection has be done for > retryHigh? I didn't find an connection.on( 'retry' ) is there something to catch that problem? an on('error') ?

No, the Connection does not emit any "retry" event, right now. I would certainly consider adding one if you'd find that helpful. For reference, the Publisher interface has something like this.

I'm not sure if there are cases where the connection is up but channel down, is there?

There are are number of situations that can produce a AMQPChannelError, which means a single channel is closed, but the connection and any other channel remains open. An example is when you attempt to publish to an exchange that does not exist.

channel.basicPublish({exchange: 'doesnotexist', routingKey: 'whatever'}, 'example-msg')
// AMQPChannelError: BasicPublish: NOT_FOUND - no exchange 'doesnotexist' in vhost '/'

This is why it's important to use the higher-level Publisher and Consumer interfaces which recreate a channel for you, when something like this happens.

It might be already handled by the .on('error'), but I didn't find a documentation on what type of errors each object can send and what they mean.

This library groups errors into three levels:

Additionally, these all have a .code property and are related through an inheritance chain (a connection error implies a channel error):

Error
  AMQPError
    AMQPChannelError
      AMQPConnectionError
const err = new AMQPChannelError()
err instanceof AMQPError // true
err instanceof AMQPChannelError // true
err instanceof AMQPConnectionError // false

Beyond that, I'm not sure documenting every possible error would be productive.