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.