Repository navigation
mcpx: correlate -32042 retries with the suspended call (no double execution) #2897
Description
Problem
PR #2886 (#2080) returns -32042 to a 2025-11-25 host while the broker keeps the pending URL questions and the original ask call stays alive (triage-settled design on #2080: no Abandon; the host completes the elicitations out of band and retries, mirroring the spec flow and the client-side flow of #2079).
Codex review on #2886 (P1, pkgs/mcpx/internal/mcpserver/ask.go) points out the asymmetry this creates in mcpx's suspended-call architecture:
- When the out-of-band flow completes,
OnElicitationComplete(internal/daemon/hooks.go) answers the broker question, so the original upstream invocation resumes and can complete the operation. - The host's retry after
-32042reachesbeginAsk, which callsAsk.Beginagain — there is norequestStateor other retry correlation in the 2025-11-25 error — so the retry starts a second upstream invocation. - For a non-idempotent operation, both executions can run.
A spec-shaped -32042 server has ended its invocation when it returns the error; mcpx has not, so the spec's retry model does not by itself prevent double execution here.
Scope / acceptance
- Decide and implement a correlation or prevention mechanism, e.g. join-on-retry in the daemon asker (a retry whose method+params match a live/completed ask with answered URL questions reattaches to that call instead of
Begin-ing a new one), or another mechanism that preserves the settled "broker keeps the questions" behaviour. - A test proving: host retries after out-of-band completion → the upstream operation executes exactly once (or the retry is answered from the original call's outcome).
- Non-idempotent pass-through calls are the case that must be safe; document what a host that retries before completion gets.
Origin
Codex P1 finding 4429651482 on PR #2886, dispositioned there as: real, but a design-level change beyond #2080's triage-settled scope (settled triggers + no-Abandon). Tracked here so the merge of #2886 does not silently ship it.
Acceptance criteria
- A host retry after a
-32042response whose out-of-band elicitations have completed does NOT start a second upstream invocation: it reattaches to (or is answered from) the original call, so a non-idempotent operation executes exactly once — proven by a test. - A retry that arrives before completion has documented, tested behaviour (no silent double execution).
- The settled mcpx: Phase 3 of #2077 — produce -32042 where it is true, register truth-up (ELI-04/09/12), and #1935 closure #2080 behaviour is preserved: the broker keeps the pending questions and no Abandon is introduced.
- CI green on the PR that implements this, including the new exactly-once test.
Activity
dezren39 commentedon Oct 31, 2026
Intake review
🤖 Agent note · filed
Still live: yes — PR #2886 (which surfaced this) is still open; no merged PR resolves this. The double-execution hazard is real per the Codex P1 cited in the body.
Related: #2080 (the
-32042behaviour that created the asymmetry), #2079 (client-side flow), PR #2886.Notes / risks: non-idempotent pass-through calls are the dangerous case; a join-on-retry keyed on method+params must not merge two genuinely distinct concurrent calls with identical params — the design needs a distinguishing rule (e.g. only join when the original's questions were answered out of band).
Suggested approach: join-on-retry in the daemon asker as sketched in the body, with the exactly-once test first.
Labels normalized:
kind/bug,priority/high(double execution of non-idempotent operations),effort/m,status/needs-triage,meta/enriched. Acceptance criteria appended to the body (its own Scope/acceptance bullets are preserved above).developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 7371 (triage, queued, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
10 remaining items
dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 4, 2026
agent-note:v1
task: 8931
lane: code-y
stage: handed_off
execution_lane: opencode
Issue #2897 verified OPEN with no hard-stop labels. Task 8931 re-claimed (attempt 11/12) and handed off to the opencode claimant, which launches the bound session. Attempts are near the cap (11/12) — if the claimant does not launch before lease expiry, the fleet monitor may need to raise the cap.
dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off
opencode, so the task is handed off — the laptop opencode-claimant launches a bound session to drive it to its terminal state. Triage task 7371 verdict CONFIRMED is posted on issue mcpx: correlate -32042 retries with the suspended call (no double execution) #2897.dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off
queue/claimed+work/assigned+status/in-progress, and no hard-stop labels (held,user/owned,do-not-merge,do-not-auto-edit) are present. Attempts 21/24.dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 5, 2026
Agent note — picked up, handed off to opencode claimant (task 8931) — AT CAP 24/24
opencode, so this worker does not work the task directly.handed_off; the laptop opencode-claimant launches the bound session for task 8931.dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off