The Client will wait for Returns until a Confirm arrives. But a Return might actually arrive after a Confirm. At which point, we might not even remember that request.
Support for basic.return and basic.ack frame ordering. This client uses Go channels for certain protocol events and ordering between events sent to two different channels generally cannot be guaranteed.
There is also some discussion in rabbitmq/amqp091 in where one of the maintainers says
Instead, deal with acks first, and if a returned message comes around, re-add ("requeue") it for re-publishing, log it, or do whatever you need to do with returns. Treat returns as a completely separate, rare occurrence, and publisher confirms as the main indicator of successful publishing. Also, if you deal with returns often, perhaps your topology is a tad too dynamic.
So we should probaly provide a way for users to listen for Returns and stop handling them in the client as errors.
The
Clientwill wait for Returns until a Confirm arrives. But a Return might actually arrive after a Confirm. At which point, we might not even remember that request.https://github.com/rabbitmq/amqp091-go#non-goals
There is also some discussion in rabbitmq/amqp091 in where one of the maintainers says
So we should probaly provide a way for users to listen for Returns and stop handling them in the client as errors.