-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Messages can be lost forever / wrongly acknowledged #142
Comments
I think you are correct. Looks like we should be finding the specific message that was acked here. |
Thanks for the sharp eyed code review! |
## [3.2.2](v3.2.1...v3.2.2) (2021-02-09) ### Bug Fixes * When messages are acked/nacked, make sure we remove the correct message from the sent messages queue. ([c662026](c662026)), closes [#142](#142)
🎉 This issue has been resolved in version 3.2.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Thanks for the quick fix, looks good! |
I woke up at 4:30am, and made the mistake of checking my email. I saw your bug, and thought, "That can't be true." And then I couldn't get to sleep until I went looking to see if it was true. :P |
The way I understand the code, everytime we call "publish", we add a new message to the in-memory queue and try to send it. Once the promise resolves (i.e. the message has been publisher confirmed), we remove the first item from this queue, wrongly assuming that this is the one which corresponds to the resolved promise.
However, according to the RabbitMQ docs, the client should not rely on the order of acknowledgements. They can come unordered.
https://www.rabbitmq.com/confirms.html
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.
The issue is that should we ever lose the connection, we will try to "re-send" the wrong messages. Some which may not have been acknowledged be lost forever, and others that were already sent will be sent again.
The text was updated successfully, but these errors were encountered: