[BUG] MCP tools/call is re-sent after '-32000 Connection closed' mid-call, so a non-idempotent tool runs twice #98466

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   area:mcp

   has reproHas detailed reproduction stepsHas detailed reproduction steps

   on Sep 30, 2026
2. Exploitacious

   added 2 commits that reference this issue on Sep 30, 2026

   fix(proxy): anchor the replay-safe 404 to the transport's own error

   ...

   dc8242a

   fix(proxy): stop re-sending tools/call after a backend timeout (#187)

   ...

   b0ef185
3. 0xdhx commented on Oct 22, 2026

   

   0xdhx

   on Oct 22, 2026

   More actions

   Adding a measurement: 2.1.307 ("Fixed HTTP MCP tool calls being sent twice when the connection closed mid-call; only read-only or idempotent tools are now retried") does what this issue asks for, on the recovery path in the logs above.

   Setup. A stdlib Python Streamable HTTP MCP server on loopback with three no-argument tools: poke (no annotations), peek (readOnlyHint: true) and nudge (idempotentHint: true). It logs every tools/call arrival, and on the first call to each tool it ends the POST's SSE response without a result. One claude -p turn per cell (Haiku 4.5), with a throwaway config dir and --strict-mcp-config. I separated client re-sends from the model calling the tool again by tool_use id: a second arrival under one tool_use id is a client re-send. The decisive cells were re-run on the unmodified release binaries.

   tools/call arrivals at the server for one model tool_use:

   tool	2.1.304	2.1.307
   poke (no hints)	2 (re-sent)	1
   peek (readOnlyHint: true)	2	2
   nudge (idempotentHint: true)	2	2

   2.1.304, poke: the same sequence as in this issue.

   MCP server "fake": MCP session expired during tool call (connection closed), clearing connection cache for re-initialization
   MCP server "fake": Retrying tool 'poke' after session recovery
   MCP server "fake": Tool 'poke' completed successfully in 3ms
   

   2.1.307, poke: the same "session expired … (connection closed)" line, no retry, and the model receives:

   MCP server "fake" connection closed before the tool call was answered. The tool may have run: check whether it did before running it again.
   

   That covers all three points under "What Should Happen?": no replay after an ambiguous close, an error that says the tool may have run, and a retry kept only for tools annotated as safe to repeat.

   Limits:

   • In my setup, the SSE response ending did not itself trigger recovery. The call stayed pending until Claude Code's own transport closed at process teardown (about 238 s into a 240 s run), and the retry decision ran then. So this verifies the decision made after connection closed, not how quickly the drop is noticed. The pending-call hang is tracked separately in [BUG] Streamable HTTP MCP: tools/call stays "still running" forever when the server dies mid-call — the client reconnects the GET stream but never fails the pending POST #104166.
   • A socket reset on a JSON (non-SSE) response, and an HTTP 503, were not retried by either build. Both came back to the model as an ordinary tool error.
4. danbryan

   added a commit that references this issue on Oct 25, 2026

   fix(proxy): stop re-sending tools/call after a backend timeout (metat…

   ...

   94bf1da
5. Ben-Home commented on Oct 27, 2026

   

   Ben-Home

   on Oct 27, 2026

   More actions

   The annotation gate removes the reported failure but not the general shape, and that is worth recording before this closes.

   readOnlyHint and idempotentHint are server authored claims. The client cannot verify them, which is tolerable for readOnlyHint (a server that lies about read only is already free to do anything) but weaker for idempotentHint, because idempotence there is a property of the input together with the server's state. A tool shaped like "append the entry if it is not already present" is idempotent under an unchanged state and is not idempotent when a different write lands in between. This retry happens seconds later on a fresh session, which is precisely when state has moved.

   So the rule that survives is narrower than the annotations suggest: retry needs proof that the request was not processed (a 404 on the session, or a transport closed before the request was written, which is the first bullet in the report), and annotations can only widen it for tools whose effects are recomputable.

   The structural fix belongs at the request, not in each client. Both attempts carry the same tool_use, so a stable idempotency key stamped by the client and passed through _meta would let the server dedupe the second call instead of re-running it. That scales to every other client, none of which will implement the same annotation policy. Without it, each client's retry rules are a private guess about someone else's side effects.

   Two smaller things from the log in the report:

   • The retry line (Retrying tool ... after session recovery) is emitted for both the safe 404 case and the unsafe mid call close, so a post mortem cannot separate them from the log alone. One field on that line, distinguishing session_404 from connection_closed_midcall, makes the two classes greppable, which is what you need when the complaint arrives days later.
   • When the client does not retry, the error should carry the "may have executed" fact as a structured field rather than prose only. A consuming harness can then choose to verify state instead of retrying on its own, which is the behaviour an agent loop actually needs here.

   For the regression, the case that matters is a server that closes after the handler completed and after a partial response was written, plus a proxy that closes while the server finishes normally. Both look identical from the client side, and both prove nothing about execution.