Received events triggered after channel is closed due to consumer_timeout (AsyncEventingBasicConsumer)

[burakergun394]

Describe the bug

In RabbitMQ.Client version 6.8.1, when using AsyncEventingBasicConsumer with manual acknowledgments (autoAck = false) and prefetchCount = 50, the client continues to trigger Received events even after the broker closes the channel due to consumer_timeout.

This results in the client processing messages that it can no longer acknowledge, which leads to those messages being redelivered — even if they were already handled by the application.

Reproduction steps

1. Create a consumer using AsyncEventingBasicConsumer.
2. Configure:
   • prefetchCount = 50
   • autoAck = false
   • consumer.Received += (s, ea) => { ... }
3. Start consuming messages.
4. Let’s say the 10th message is being processed.
5. Do not send an Ack for this message for a while (in the test, the timeout was lowered, but the default is 30 minutes).
6. The broker closes the channel due to consumer_timeout.
7. The client still invokes Received for the remaining prefetched messages (messages 11–50).
8. These messages are processed, but any attempt to Ack them fails with an RabbitMQ.Client.Exceptions.AlreadyClosedException: Already closed: The AMQP operation was interrupted: AMQP close-reason, initiated by Peer, code=406, text='PRECONDITION_FAILED - delivery acknowledgement on channel 1 timed out.Timeout value .....

Expected behavior

Once the channel is closed by the broker due to consumer_timeout:

• Is it expected that the client continues to invoke Received for messages that can no longer be acknowledged?
• Alternatively, should the application explicitly check if the channel is still open before processing each message?

Clarification on the expected behavior — and whether this has changed in newer client versions (e.g., 7.x) — would be appreciated.

Additional context

In real-world applications, the Received event is often the entry point for a business transaction. Developers typically assume that if the event is fired, the message is safe to process and acknowledge.

If the client continues to deliver messages after the channel has already been closed, this may lead to:

• Successfully processed messages being redelivered
• Duplicate handling
• Inconsistent application state

This becomes especially critical in systems that rely on at-least-once or exactly-once delivery guarantees.

Understanding whether this behavior is intentional or has been addressed in newer versions (like v7.x) would be very helpful.

[michaelklishin]

The prefetched messages were delivered to the client, so it is expected that they will be passed on to the callbacks.

The channel can be closed during delivery processing, by RabbitMQ or your application. Your application's state management is not a responsibility of this client.

[lukebakken]

Developers typically assume that if the event is fired, the message is safe to process and acknowledge

They should NOT assume that, why in the world would they? In the extreme case, RabbitMQ could disappear before acking a message.

If your HTTP GET request succeeds, does that automatically mean your next request will as well?

Please provide code that I can clone, compile, and run, to observe this behavior. Include the necessary RabbitMQ configuration to lower the consumer timeout, and thus more easily trigger the behavior.

I could do all of that, but it's time wasted that I could use to improve the behavior in this scenario.

should the application explicitly check if the channel is still open before processing each message?

Yes, this is the preferred method at this time.

Please note that it's possible for a channel to be closed as an acknowledgement is in-flight for a message. That message will be requeued and redelivered.