Quorum Queue requeueing does not return to the back of the queue as expected

[caspervk]

Describe the bug

I am trying to implement a system where consumers processes as many messages as possible from a queue, skipping any unprocessable ones, but leaving them in the queue for later. I was hoping to implement this using Quorum Queues, as the documentation states that:

Messages that are rejected or nacked back to a quorum queue will be returned to the back of the queue if no delivery-limit is set.

Based on this, I switched my queues from classic to quorum and expected to see the consumer process each message, skipping (requeuing) any unprocessable ones, and ending up "rotating" through the failed ones. Instead, I am observing that the first unprocessable message blocks the queue, and is continuously processed over and over by the consumer. According to this thread on the mailing list:

Internally [a quorum queue] keeps a single separate queue for returned messages which is emptied before the main queue. So once a message has been returned it will be served before other messages. That said the return queue works as a simple FIFO queue so once it has been returned once it will join the back of the returns queue, as you have noticed.

This seems to imply that quorum queues can not solve my use case. Is the documentation misleading?

Reproduction steps

1. Create a Quorum Queue with no delivery-limit.
2. Add two messages to the queue.
3. Get and requeue a message (A).
4. Get another message, I expect this to be message B.
5. Observe that the second message retrieved is message A, not message B.

Expected behavior

I expect to retrieve message B.

Additional context

No response

[kjnilsson]

Which version of RabbitMQ are you using for testing this?

[caspervk]

Thank you for the quick reply! I initially tested using RabbitMQ 3.11.13.. I have just reproduced on RabbitMQ 3.12.6 using the management interface through docker.

[kjnilsson]

Ok it seems like if you use basic.reject it works as described but if you use basic.nack it doesn't.

[caspervk]

Yeah, that does indeed seem to work. I'll see if I can get it working in my application, thanks a lot!

[lukebakken]

Thanks @kjnilsson

[Skeen]

This still seems to be a problem:

Messages that are rejected or nacked back to a quorum queue will be returned to the back of the queue if no delivery-limit is set.

Either the implementation should have the rejecting behavior in nacking cases, or the documentation should be adjusted.

[kjnilsson]

This turned out to be a quirk of the managment UI which has been addressed in rabbitmq/rabbitmq-server#9715

When using a client library it always works as documented.

[kjnilsson]

This turned out to be a quirk of the managment UI which has been addressed in rabbitmq/rabbitmq-server#9715

When using a client library it always works as documented.