fleet/fleetd
3
0
Fork 0
Code Issues 105 Pull Requests 2 Actions Packages Projects Releases 1 Wiki Activity

fleetd #808: a late fleet_reply claims its turn's waiter, suppressing the duplicate completion scrape #810

Closed
agent wants to merge 0 commits from worker/808-0c71eb-2 into main
pull from: worker/808-0c71eb-2
merge into: fleet:main
Conversation 0 Commits - Files Changed -
agent commented 2026-10-07 07:03:06 +02:00
Member
Copy Link
Copy Source

Fixes #808 (regression from #801): after a blocking fleet_send times out, an explicit fleet_reply for that turn landed in the inbox, and the later CB-106 completion-fallback scrape for the same turn landed a second time.

Fix. reply() now looks up the exact Rendezvous waiter strandLateResolution captured for the target (a new lateWaiters map, target -> that turn's CompletableFuture<Resolution>) and claims it via a new Rendezvous.resolveLateReply before falling back to publishing to the inbox. The discriminator is the waiter's own single-winner complete() call — per-turn by construction, since each send() opens a fresh CompletableFuture per turn. Whichever side (the explicit reply or the eventual completion scrape) resolves the waiter first wins; the loser's attempt is a no-op. CompletionResolver.resolve's existing waiter.isDone() guard then skips the scrape entirely once the waiter is already claimed, so nothing extra is ever read or published.

I deliberately avoided the banned discriminator (a sticky per-target boolean like strandedReplies) — that would also suppress a later, independent turn's legitimate completion on the same target. The per-turn waiter-identity race does not have that problem, since lateWaiters is overwritten with a fresh waiter reference on every new timeout.

Tests (MessageServiceTest):

  • anExplicitReplyAfterATimeoutLandsExactlyOnceNotTwice — reply direction: exactly one inbox entry, the structured reply.
  • theSuppressionIsPerTurnNotPerTarget — two turns on the same target: the first gets an explicit reply (its own late scrape stays suppressed), the second never replies and its scrape still lands exactly once.
  • The no-reply direction was already covered by the existing `aCompletionThatArrivesAfterTheCallerGaveUpLandsInTheInbox" test (#801), unaffected by this change.

Measured. mvn clean install from the repo root: BUILD SUCCESS, Tests run: 2246, Failures: 0, Errors: 0, Skipped: 0. MessageServiceTest alone: 119 tests, 0 failures, 0 errors.

Scope: only MessageService.java, Rendezvous.java, and MessageServiceTest.java touched.

Fixes #808 (regression from #801): after a blocking `fleet_send` times out, an explicit `fleet_reply` for that turn landed in the inbox, and the later CB-106 completion-fallback scrape for the same turn landed a second time. **Fix.** `reply()` now looks up the exact `Rendezvous` waiter `strandLateResolution` captured for the target (a new `lateWaiters` map, target -> that turn's `CompletableFuture<Resolution>`) and claims it via a new `Rendezvous.resolveLateReply` before falling back to publishing to the inbox. The discriminator is the waiter's own single-winner `complete()` call — per-turn by construction, since each `send()` opens a fresh `CompletableFuture` per turn. Whichever side (the explicit reply or the eventual completion scrape) resolves the waiter first wins; the loser's attempt is a no-op. `CompletionResolver.resolve`'s existing `waiter.isDone()` guard then skips the scrape entirely once the waiter is already claimed, so nothing extra is ever read or published. I deliberately avoided the banned discriminator (a sticky per-target boolean like `strandedReplies`) — that would also suppress a later, independent turn's legitimate completion on the same target. The per-turn waiter-identity race does not have that problem, since `lateWaiters` is overwritten with a fresh waiter reference on every new timeout. **Tests** (`MessageServiceTest`): - `anExplicitReplyAfterATimeoutLandsExactlyOnceNotTwice` — reply direction: exactly one inbox entry, the structured reply. - `theSuppressionIsPerTurnNotPerTarget` — two turns on the same target: the first gets an explicit reply (its own late scrape stays suppressed), the second never replies and its scrape still lands exactly once. - The no-reply direction was already covered by the existing `aCompletionThatArrivesAfterTheCallerGaveUpLandsInTheInbox" test (#801), unaffected by this change. **Measured.** `mvn clean install` from the repo root: `BUILD SUCCESS`, `Tests run: 2246, Failures: 0, Errors: 0, Skipped: 0`. `MessageServiceTest` alone: 119 tests, 0 failures, 0 errors. Scope: only `MessageService.java`, `Rendezvous.java`, and `MessageServiceTest.java` touched.
agent added 1 commit 2026-10-07 07:03:07 +02:00
fleetd #808: a late fleet_reply claims its turn's waiter so the completion scrape cannot double-publish
CI / shell-tests (pull_request) Failing after 9s
Details
CI / contract (pull_request) Successful in 55s
Details
CI / build (pull_request) Failing after 2m19s
Details
CI / shell-tests (push) Failing after 9s
Details
CI / contract (push) Successful in 46s
Details
CI / build (push) Failing after 2m3s
Details
0ff0d6cb02 
A send that times out leaves its captured Rendezvous waiter open for the CB-106
completion fallback (strandLateResolution). If the member then calls fleet_reply,
reply() found no live waiter and queued the answer to the inbox, but never touched
that captured waiter — so the eventual completion fallback still resolved it and
published a second, redundant scrape of the same turn.

reply() now looks up the exact waiter strandLateResolution is tracking for the
target (lateWaiters, a new per-target index onto a per-turn CompletableFuture) and
claims it with Rendezvous.resolveLateReply before falling back to the inbox. The
CompletableFuture's own single-winner complete() is the discriminator: whichever
side resolves it first decides what the other sees. A later completion scrape
against an already-claimed waiter is a no-op in CompletionResolver.resolve's
existing waiter.isDone() check, so nothing is scraped or published a second time.
A turn that never gets an explicit reply is unaffected — its own waiter is still
open when the completion fallback fires, exactly as #801 already fixed.
ltms closed this pull request 2026-10-07 07:09:48 +02:00
Some checks are pending
CI / shell-tests (pull_request) Failing after 9s
Details
CI / contract (pull_request) Successful in 55s
Details
CI / build (pull_request) Failing after 2m19s
Details
CI / shell-tests (push) Failing after 9s
Details
CI / contract (push) Successful in 46s
Details
CI / build (push) Failing after 2m3s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
blocked
Cannot start until something else lands. The body says what.
 needs-live-proof
Merged and green, but never shown working on the running daemon. Not the same as done.
 ready-to-delegate
Scope, files and acceptance criteria are written. A worker can be briefed from the body alone.
 silent-default
A feature that compiles, passes tests, and ships turned off. Nine recurrences and counting.
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent kevin ltms
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fleet/fleetd#810
Delete Branch "worker/808-0c71eb-2"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?