Bridge v2 agent_handshake_next dependency waits with bounded server-side waiting - #121
Merged
Merged
Conversation
…ide waiting Production canaries showed a public client (Codex) ending its turn after a normal awaiting_funding/awaiting_counterpart response even though the body asked for a retry. Model-managed polling is unreliable at this tool boundary, so agent_handshake_next now holds a single call for a bounded waitMs (default 12s, max 15s, opt-out with 0), long-polling the relay for new messages after the observed highestSeq cursor and re-evaluating until an actionable, terminal, or deadline-bounded outcome. Every wait body now carries retryAfterMs plus nextAction; awaiting_counterpart, awaiting_proposal, awaiting_descriptor, awaiting_anchors, and awaiting_certificate gain the missing nextAction. waitMs is threaded schema -> broker -> coordinator -> relay, where it is clamped to 60s on the wire. Constraint: must not exceed likely MCP client timeouts; 15s max stays well under them while bridging funding-visibility and counterpart gaps. Rejected: harness relaunch/resume as primary fix | certifies the harness, not the public client/tool contract; local MCP proxy | new trust component. Confidence: high Scope-risk: narrow Directive: keep waitMs clamped at or below 15s and never sleep past sessionDeadlineMs; the cursor must always advance past observed highestSeq or the poll replays the backlog and spins. Tested: mcp-server 452/452 incl. funding-visibility->register, counterpart/ proposal->sign_acceptance, certificate wait, timeout body preservation, deadline clamp, immediate actionable/terminal paths, waitMs validation, cursor-cursor long-poll, relay waitMs forwarding; all workspaces 675/675. Not-tested: live funded canary (held pending exact-SHA review + deploy).
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.
Summary
agent_handshake_nextnow bridges ordinary dependency waits server-side: optionalwaitMs(default 12s, max 15s,0disables) threaded schema -> broker -> coordinator -> relay long-poll.highestSeqcursor (never replays backlog / spins), clamps to remainingsessionDeadlineMs, and is bounded byMAX_NEXT_WAIT_POLLS.retryAfterMs+nextAction;awaiting_counterpart,awaiting_proposal,awaiting_descriptor,awaiting_anchors,awaiting_certificategained the missingnextAction.getMessagesacceptswaitMs, clamped to 60s on the wire.Test plan
Exact-SHA review: PASS on 8834593.