consumer acks and nacks on multiple messages - could we ever support a LIST of message IDs?

[Matt Callaghan]

Good day RabbitMQ maintainers & experts,

As per https://www.rabbitmq.com/confirms.html#consumer-acks-multiple-parameter, we understand that RabbitMQ consumers can ACK (or NACK) multiple messages at once using the "multiple=true" flag.

As described, this (N)ACKs ALL message IDs <= the one supplied.  But this assumes: message IDs are in order and incremenatal (we're not sure if this is guaranteed)?

Further, if implementations are working in batches, one thread per channel, the implementation of this in reality requires careful concerns over:

1. ORDERING

2. NACK vs. ACK

Consider a bulk of 10x message IDs. Say:

A) 1,2,3 = GOOD, ACK

B) 4 = BAD, need to requeue (NACK)

C) 5,6,7 = GOOD, ACK

D) 8,9 = BAD, need to requeue (NACK)

E) 10 = GOOD, ACK

This requires a careful IN ORDER processing of each case, as individual requests, as a sort of "sub-batching", delineation at each point of a change in response.... having to break up the calls into precisely that order of A,B,C,D,E.

A) ACK(3, true)

B) NACK(4)

C) ACK(7, true)

D) NACK(9, true)

E) ACK(10)

, and if any one of those calls fails, the whole logic is thrown up in the air ... (NACK all? bail and retry? = duplicate data of the batch, quickly becomes difficult and messy)

Could RabbitMQ not support "lists of message IDs" instead?  It would be far more performant if the client could could make TWO calls:

i) ACK: 1,2,3,5,6,7,10

ii) NACK: 4,8,9

(perhaps there is some underlying protocol limitation that prevents this?)

Thank you in advance

[Matt Callaghan]

is a "ping" acceptable here?