Pi adopts the DispatchGuard - #51
Draft
jimutt wants to merge 1 commit into
Draft
Conversation
DL-024 item 7, pi side. The pi loop's anti-spam was token + claim: the token voids stale dispatches, and claiming the item before dispatching means the next agent_end sees it as in-flight. But there was no bound on re-delivery — an agent_end that doesn't advance the item re-dispatches identically forever, masked by the hidden followUp. Now the guard sits between the token check and the claim. First suppression re-delivers once, second surfaces a wedge notification. Invalidation clears the guard so a resumed run dispatches fresh. Two new tests: the wedge path and the invalidation-clears-guard path. All suites green: 142 bun, 305 bats, tsc, tessl. Co-Authored-By: Kimi K3 <noreply@pi.dev> Generated-By: pi 0.84.2
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
1 participant
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.
What
Pi adopts the DispatchGuard: bounded re-delivery and wedge detection in the continuation loop.
Why
DL-024 item 7's pi side. The loop's anti-spam was token + claim — effective against stale dispatches, but with no bound on re-delivery. An agent_end that doesn't advance the item re-dispatches identically forever, masked by the hidden followUp. The DispatchGuard (extracted in #49) now bounds it.
What changed
guard.classify("pi", dispatchKey)between the token check and the claim. First suppression re-delivers, second surfaces a wedge notification, further suppressions stay quiet.invalidate()clears the guard — a resumed run dispatches fresh.Stacks on v1 (the merged DL-024 stack).
Test coverage
142 bun tests (2 new), 305 bats, tsc, tessl — all green.