fix: dispatch AMQP acknowledgements to the owning connection - #146
Draft
robjarawan wants to merge 2 commits into
Draft
fix: dispatch AMQP acknowledgements to the owning connection#146robjarawan wants to merge 2 commits into
robjarawan wants to merge 2 commits into
Conversation
Test Results385 tests 384 ✅ 1m 42s ⏱️ Results for commit 24141ec. |
This was referenced Sep 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #145.
I changed
Gather.ack()to check the existingconnection_idbefore handing an AMQP acknowledgement to a consumer. Previously, the first consumer on the same broker erased the second consumer'sack_id, so the owning connection never acknowledged that delivery.I reproduced this with a disposable RabbitMQ 4.3.5, parsed subscriptions, real gather/acknowledgement calls and a queue check after closing the consumers. Both
amqpandamqpconsumerredelivered subscription 1's message on the baseline. With the fix, neither backend redelivers either message. The single-subscription controls pass before and after.4 failed, 7 passed11 passed364 passed, 1 skipped, 1 failedThe remaining broader failure is the existing clock-dependent
test_schedules. I kept the stale-connection, changed-channel and transport-error controls so the fix preserves the recovery behavior from upstream #1155 and #1278. No ACK retry loop or reconnect was added. Protocols withoutconnection_idkeep their existing dispatch behavior.For the real-broker reproduction, start a disposable RabbitMQ on loopback with the standard local
guestfixture account, then run:The script creates uniquely named queues/exchanges, publishes synthetic messages, reports actual redeliveries and removes only its own resources. The same script exits
1on the baseline and0with the fix.The runtime fix and tests are in
11ac81734. I carried the separate CI repair from #140 for local maintenance fixtures and exclusion of live-feeddynamic_flowjobs. This remains a draft pending the broader flow matrix and independent review.