Messages being retroactively nack'd in confirm mode with queue limits

I run a single producer and consumer (both using SelectConnection), writing to and reading from a single queue whose maximum size has been limited:

{
    'x-max-length': 10,
    'x-overflow': 'reject-publish'
}

Channels are configured with publisher confirms (confirm_delivery) and log the individual acks and nacks. Sometimes (about once in 50k messages), a nack will occur that contradicts a multi-ack immediately before it. The confirmation messages seem to have been reacted to in the wrong order. An example:

2018-01-02 18:31:56,763 - root - INFO - ack multi 3460 
2018-01-02 18:31:56,763 - root - INFO - nack multi 3459 

Messages up to tag 3460 are ack’d but then those up to 3459 are nack’d. This causes the nack’d messages to be lost (since they are never republished). Things would have worked fine had the messages been processed in the opposite (and correct) order.

Is there something obviously wrong I might be doing? Please let me know if I can provide you with any more information. I’m using pika 0.11.2 with RabbitMQ 3.7.1. The issue persists when using pika’s master as well.

[vitaly-krugl]

@sbidin, @lukebakken: I think I may have found a possible bug in user code that can explain this issue:

    def _on_message_nack(self, tag_to: int, multiple: bool) -> None:
        tag_from = self.last_nack + 1 if multiple else tag_to
        ....

I think that the line tag_from = self.last_nack + 1 if multiple else tag_to should instead be

tag_from = max(self.last_nack, self.last_ack) + 1 if multiple else tag_to

because the multi-nack would presumably apply to all messages since the most recent ack or nack from the broker.

And ditto regarding user’s _on_message_ack() implementation.

[vitaly-krugl]

@lukebakken, since the queue is configured to Max out at 10, I suspect this becomes reproducible when the consumer process is occasionally not keeping up with the producer.