How to robustly handle delivery acknowledgement timeout

[ClemDoum]

Community Support Policy

• I have read RabbitMQ's Community Support Policy

RabbitMQ version used

4.0.2

Use case description

I'm using https://github.com/mosquito/aio-pika to build an RabbitMQ based application where queues use delivery acknowledgement timeouts.

When timeout occur I get the following (and expected) error:

PRECONDITION_FAILED - delivery acknowledgement on channel 2 timed out. Timeout value used: 60000 ms. This timeout value can be configured, see consumers doc guide to learn more

However, since I'm using aiopika's RobustChannel which re-opens the connection when it's closed, my consumer re-opens a channel and continues processing, defeating the purpose of the delivery acknowledgement timeout.

This happens because when the channel is closed, aiopika doesn't keep track of why it was closed and reopens it whatever happens.

I would like to change that behavior so that the channel is not re-open when a consumer timeout occurred, however I'm left with the following question

How to robustly identify delivery acknowledgment timeout when it occurs ?

Looking at the server code I see that a generic precondition_failed error is raise with a specific consumer timeout message.

From the client perspective how can I distinguish/isolate the consumer timeout case from other precondition_failed exceptions ?

I'm tempted to parse the error message, however can I have strong guarantees that it will be stable across non breaking version of the rabbitMQ server ?

What strategy do you advise to robustly isolate consumer timeouts when it happens ?

[lukebakken]

In general, if you get a consumer timeout, the opinion of Team RabbitMQ is that your application has a bug.

In this case, you will have to parse the error message.

can I have strong guarantees that it will be stable across non breaking version of the rabbitMQ server

The message probably won't change. I'm not sure if we have the option for a different AMQP error to be returned in this case (cc @michaelklishin ?)

[ClemDoum]

Thank you for your answer.

I agree with the fact the consumer timeout denotes app bugs, aiopika shouldn't "swallow" the error and reopen the channel without letting the user notice it. I'll try to make a contribution in that direction if possible.

I'll will parse the error message for now !

[michaelklishin]

Reopening channels in response to exceptions is something that no official client library does because the library does not have enough context to make a sound decision.

Consumer timeouts should be visible in user code as an exception (or similar), they absolutely should not be handled automatically by the client library.

The message is unlikely to change simply because we do not plan to tweak this behavior. It does what it was meant to do: requeue messages that consumers fail to acknowledge during 30 or 60 minutes after delivery (the default has changed over time).

[ClemDoum]

Perfect, thank you for your answers @michaelklishin, I'll try to contribute to aiopika in that direction !