fix(streamable-http): reject duplicate in-flight request ids

[Sammy-Dabbas]

Fixes #3060.

The stateful streamable HTTP transport keys per-request routing by the request id and assigns the slot without an existence check. Two concurrent POSTs sharing an id cross-wire: the second overwrites the first's routing slot, the first request's response is delivered to the second POST, and the first hangs while its stream leaks. Reproduced on main before the fix.

This adds a guard in _handle_post_request that rejects a POST whose request id is already in flight on the session with HTTP 400 and JSON-RPC -32600, placed before the JSON/SSE branch so both response modes are covered. The spec requires request ids to be unique within a session. Sequential reuse of an id after the earlier request completes still works, since deployed clients send a constant id for every request; a regression test pins that behavior.

Tests: the new duplicate-id test fails on unpatched main and passes with the fix. tests/shared/test_streamable_http.py passes 67/67 and the full suite passes locally (5282 passed). A stress run of 500 rapid sequential same-id requests produced no spurious rejections. ruff and pyright are clean on the touched files.

Scope note: this is the transport-level guard only. The dispatcher-level blind overwrite in jsonrpc_dispatcher.py (TODO from #3046) is deliberately left to the follow-up discussed on the issue, since the two guards compose.

Disclosure: this change was developed with AI assistance (Claude Code). I reviewed the change and the test results before submitting.

[cubic-dev-ai]

1 issue found across 2 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/mcp/server/streamable_http.py">

<violation number="1" location="src/mcp/server/streamable_http.py:558">
P1: Duplicate in-flight IDs can still slip through in resumable SSE mode because the new guard runs before an awaited priming step. When `_mint_priming_event()` awaits event-store persistence, a second concurrent POST with the same `id` can pass the `request_id in self._request_streams` check before the first request is registered, so routing can still be overwritten. Reserving the request id in in-flight state before any await (or using a separate in-flight reservation set) would close this race.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: Duplicate in-flight IDs can still slip through in resumable SSE mode because the new guard runs before an awaited priming step. When _mint_priming_event() awaits event-store persistence, a second concurrent POST with the same id can pass the request_id in self._request_streams check before the first request is registered, so routing can still be overwritten. Reserving the request id in in-flight state before any await (or using a separate in-flight reservation set) would close this race.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/mcp/server/streamable_http.py, line 558:

<comment>Duplicate in-flight IDs can still slip through in resumable SSE mode because the new guard runs before an awaited priming step. When `_mint_priming_event()` awaits event-store persistence, a second concurrent POST with the same `id` can pass the `request_id in self._request_streams` check before the first request is registered, so routing can still be overwritten. Reserving the request id in in-flight state before any await (or using a separate in-flight reservation set) would close this race.</comment>

<file context>
@@ -549,6 +549,20 @@ async def _handle_post_request(self, scope: Scope, request: Request, receive: Re
+            # responses (one request receives the other's payload, the other hangs).
+            # The spec requires ids to be unique within a session; ids may still be
+            # reused once the earlier request has completed. See #3060.
+            if request_id in self._request_streams:
+                response = self._create_error_response(
+                    f"Bad Request: Request id {request_id} is already in flight for this session",
</file context>