Streamable HTTP server silently drops in-flight request when client reuses a JSON-RPC id

[dexteradeus]

Summary

When a client sends two JSON-RPC requests with the same id on the same Streamable HTTP session before the first response is delivered, StreamableHTTPServerTransport overwrites the per-id response stream slot without warning. The first request's caller hangs until its read times out, and the second response is delivered to whichever caller wins the race. The server logs nothing.

The MCP base protocol requires that "the request ID MUST NOT have been previously used by the requestor within the same session," so a duplicate id is a protocol violation by the client. But the server has no way to tell the client (or an operator) that the violation happened, which makes this very hard to diagnose downstream.

Where it happens

In src/mcp/server/streamable_http.py lines 534-536 at v1.27.1:

request_id = str(message.root.id)
self._request_streams[request_id] = anyio.create_memory_object_stream[EventMessage](0)
request_stream_reader = self._request_streams[request_id][1]

The assignment is unconditional. If request_id is already a key in _request_streams, the prior (send, receive) pair is dropped on the floor. The earlier request's writer eventually tries to push a response into a stream nobody is reading, and the earlier request's caller is reading a stream nobody will ever write to.

The router side at lines 1004-1033 uses the same str(id) keying to dispatch responses, so once the slot has been overwritten, response routing is undefined.

Reproduction signature

We hit this through an in-house client that was sending id: 1 for every concurrent tool call on a shared session. Under concurrent load, calls timed out and at least one caller received the wrong tool's response payload.

Proposed Behavior

When a request arrives with an id that already has an in-flight stream registered, the server should reject it with JSON-RPC -32600 Invalid Request and leave the existing in-flight request untouched. This:

1. Surfaces the spec violation to the client immediately instead of timing out.
2. Preserves the in-flight request that arrived first.
3. Gives operators a log line to diagnose against.

A weaker variant (log-only, no error response) would still be a meaningful improvement over silent data loss.

[truffle-dev]

Confirmed at HEAD on v1.x. The unconditional dict assignment is still present at src/mcp/server/streamable_http.py:536 (line 529 on main). When request_id already keys an in-flight stream, the prior (send, receive) pair is dropped on the floor exactly as you described. The earlier handler's request_stream_reader then reads a closed stream, and the response router at line 1006 routes the response to whichever stream happens to be live.

The existing GET_STREAM_KEY in self._request_streams collision check at line 690 is the precedent for the fix shape:

request_id = str(message.root.id)
if request_id in self._request_streams:
    response = self._create_error_response(
        f"Conflict: request id {request_id!r} is already in flight on this session",
        HTTPStatus.CONFLICT,
    )
    await response(scope, receive, send)
    return
self._request_streams[request_id] = anyio.create_memory_object_stream[EventMessage](0)

This matches the GET-stream conflict (409 + _create_error_response) and preserves the in-flight request untouched.

One nuance worth a maintainer call: the existing helper builds the JSONRPCError with id=None. For most callers that's correct (parse errors before id is known), but here the client knows the id. Mirroring the existing helper keeps the diff one-call; threading the offending id through would require either a new helper signature or an inline JSONRPCError construction. I'd lean on the helper for consistency but can go either way.

Happy to send the PR ([v1.x] target, with a regression test that seeds _request_streams[request_id] and POSTs the duplicate) if it's welcome. Targeting v1.x since this is a non-breaking server-side bug fix per AGENTS.md.