Open lfse-slafleur opened 1 month ago
It appears the the culprit is here: https://github.com/mosquito/aio-pika/blob/master/aio_pika/queue.py#L469
. The message is NACK'ed and multiple is set indiscriminetely, even if the deliver-tag of other messages belongs to other subscriptions & queues.
Workaround: Keep each queue & subscription in a separate channel. This prevents from the 'multiple = True' part of the NACK to not reference deliveries of other queues & subscriptions.
I am working on a test case to reproduce the issue as well as a fix. Should be relatively easy to fix by not nack'ing multiple messages but rather the messages that have been received. RabbitMQ should reschedule it the moment the subscription is removed without nack'ing or ack'ing the message anyways.
Hello!
Thank you for aio-pika, it is a great library.
I have been running into some issues when using aio-pika in the orchestrator component for another opensource project called OMOTES (https://github.com/Project-OMOTES/orchestrator/). We use aio-pika to create quite a few queue's, receive 1 or more messages on the queue and delete the queue after. Now, we have found an issue where occassionally Rabbitmq (3.12.14-management) raises a
PRECONDITION_FAILED - unknown delivery tag
exception to the subscriber of the queue's.Using wireshark, I have managed to analyze the issue. Attached: rabbitmq_unknown_delivery_tag.zip
Context:
tcp.port == 49146
test_{0,1,2,3,4,5,6,7,8,9}
.ready!
to the queueready
.test_{0,1,2,3,4,6,7,8,9}
queues.This leads to the issue as analyzed in the attached wireshark pcap:
PRECONDITION_FAILED - unknown delivery tag 16
being raised by RabbitMQ.delivery tag 16
is NACK'ed.unknown delivery tag
error as delivery tag 16 is now NACK'ed twice.This is also documented here: https://www.rabbitmq.com/amqp-0-9-1-reference#basic.nack.multiple
Couple of more comments regarding this issue:
ctag1.fd3c37a647bf42acba3c4733626804c2
and is received from queuetest_7
ctag1.cee0f236c17e4ac3a8624d8431166ab6
and is received from queuetest_6
In order to reproduce this issue more easily, I have prepared the following subscriber and producer scripts:
To start the necessary rabbitmq:
docker run --rm -ti -p "5672:5672" -p "15672:15672" rabbitmq:3.12-management
Tested with aio-pika 9.3.1 and rabbitmq 3.12.14-management