I am writing a wrapper around the .NET RabbitMQ library and have a question that isn't answered in the documentation as far as I can see, and I can't think of a way to verify it experimentally.
The documentation here states the following:
In most cases, RabbitMQ will acknowledge messages to publishers in the same order they were published (this applies for messages published on a single channel). However, publisher acknowledgements are emitted asynchronously and can confirm a single message or a group of messages. The exact moment when a confirm is emitted depends on the delivery mode of a message (persistent vs. transient) and the properties of the queue(s) the message was routed to (see above). Which is to say that different messages can be considered ready for acknowledgement at different times. This means that acknowledgements can arrive in a different order compared to their respective messages. Applications should not depend on the order of acknowledgements when possible.
So confirmations can be received out of order which I can cope with OK. However, how does this play with the Multiple flag that can be used?
Imagine the following scenario: I send messages 1,2,3,4 and 5. 1 fails and 2-5 succeed. The broker sends me a Nack for 1 and a single Ack for 5 with Multiple set to true. If order were guaranteed then I know I would get the Nack for 1 first and then I would know that the Ack was for 2-5. However, if they could be out of order, then I would assume, as I hadn't had a confirm for 1, that the Ack was for 1-5, and then when the Nack came in, it would be too late.
Are there guarantees somewhere where this scenario cannot happen?
