-
Notifications
You must be signed in to change notification settings - Fork 63
fix(broker): withhold fleet delivery_ack until worker confirms injection #1543
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
Open
miyaontherelay
wants to merge
3
commits into
main
Choose a base branch
from
fix/relay-1310-echo-verified-ack
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
210bf83
fix(broker): withhold fleet delivery_ack until worker confirms injection
miyaontherelay ec659a5
fix(broker): tie withheld fleet acks to delivery lifetime, not a seco…
miyaontherelay f8ee6e7
fix(broker): persist withheld fleet ack across broker restart
miyaontherelay File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
P1: After restart, restoring withheld acks without restoring the fleet cursor can acknowledge lower-sequence deliveries that are still pending. If multiple in-flight deliveries for one agent are replayed out of order, confirming seq 2 first makes
commit_deliveredadopt seq 2 on the empty book and sends a cumulativedelivery_ackthrough seq 2; a later failure of seq 1 then loses that message. Restore the fleet cursor and replay in sequence order, or only resolve a restored ack when all lower pending sequences for that agent have been confirmed.Prompt for AI agents
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirmed real, and I want to flag this is more than a theoretical edge case, not something to patch quickly under merge pressure — I'm recommending against merging f8ee6e7 as-is until this is properly addressed.
Mechanism, traced in code:
load_pending_deliveriessetsnext_retry_at: Instant::now()on every restored delivery — "retry immediately on restart" (a pre-existing, correct design for the retry itself). Butmaintenance.rs's sweep collects due deliveries viapending_deliveries.iter().filter_map(...)over aHashMap<DeliveryId, PendingDelivery>— hash iteration order, not insertion or seq order. So after any restart with 2+ pending deliveries queued for the same agent, there is no ordering guarantee at all on which one gets retried/injected/echo-confirmed first. This isn't rare — it's a coin flip for any agent with backlog at crash time.Once that happens,
FleetDeliveryBook::commit_received's "adopt first position" branch (fires whenever!cursor.has_sequenced_position, which is unconditionally true for every agent in the fresh post-restart book) takes whichever seq confirms first as the baseline and immediately advances the cumulativeacked_up_to_seqto it viacommit_delivered'scommit_acked_receiptcall. If that first-confirmed delivery has a higher seq than a sibling still outstanding, the engine gets a cumulative ack claiming everything through that seq is delivered — including the still-unconfirmed lower one. If that lower one later dead-letters, the engine never learns it wasn't delivered (exactly as you described).Why I'm not patching this in-place right now: I worked through the obvious mitigation — pre-seeding the book's per-agent cursor to
min_pending_seq - 1for restored deliveries before any resolve. That closes the false cumulative ack half, but not the whole bug: the higher-seq delivery's own confirmation, arriving first, would then hit the strict+1-adjacency guard incommit_acked_receipt, resolve to a stale/duplicate ack instead of its own, and itsPendingDeliveryentry is already gone (removed byclear_pending_delivery_if_event_matchesbeforeresolve_pending_fleet_ackruns) — nothing re-triggers its ack once the lower sibling catches up. That trades "silent permanent loss" for "the engine may later redeliver an already-injected message" (duplicate injection) rather than eliminating the hazard. A correct fix needs an actual per-agent hold-and-release-in-order mechanism for restored withheld acks (your first suggestion — restore/replay the cursor in sequence order), which is real design + implementation work I don't think should happen rushed against a merge deadline.Recommendation: treat this as blocking, or merge with this explicitly called out as a known limitation + tracked immediate follow-up if the narrower risk window (restart + 2+ pending deliveries to the same agent + out-of-order confirmation) is judged acceptable short-term. That's chief's/Khaliq's call to make with this information, not mine to make silently. I'll implement the proper hold-and-release fix now if that's the decision.