RabbitMQ: quorum-queue attempt counting never advances on RabbitMQ 4.3+ (basic.nack does not increment x-delivery-count)

[brenpike]

Found during the README overhaul (branch docs/readme-overhaul, local review finding 2b77501c). The README now documents this as a known limitation.

Problem

On quorum queues the receiver settles a failed delivery with BasicNackAsync(deliveryTag, multiple: false, requeue: true) (src/Chatter.MessageBrokers.RabbitMQ/src/Chatter.MessageBrokers.RabbitMQ/Receiving/RabbitMqReceiver.cs:467-469) and reads the attempt count only from the native x-delivery-count header (:56, :367, :626).

According to the RabbitMQ quorum queue docs ("When is delivery count incremented?") and the 4.3.0 release notes, from RabbitMQ 4.3 an AMQP 0.9.1 basic.nack with requeue increments the acquired-count, not the delivery-count, and explicit returns are unlimited. The queue delivery-limit is based on delivery-count.

So on RabbitMQ 4.3+ a message that keeps failing:

• never advances x-delivery-count, so maxReceiveAttempts is never reached and it is never routed to the Error Queue by Chatter;
• never reaches the broker delivery-limit either.

It is redelivered indefinitely (a poison-message loop). No data loss.

CI gap

Integration tests pin rabbitmq:3.13-management (tests/Integration/RabbitMqFixture.cs:24), so 4.3 behaviour is never exercised.

Candidate fixes

• Settle failures with basic.reject (requeue) if that still increments delivery-count on 4.3, or
• read x-acquired-count as well as x-delivery-count when computing attempts, and/or
• add a 4.x fixture to CI.

Verify the exact 4.3 semantics against a real broker before choosing.