René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Dispatcher mints a request id already used by a completed caller-supplied request (spec: ids MUST NOT be reused in a session)","articleBody":"### Initial Checks\n\n- [x] I confirm that I'm using the latest version of MCP Python SDK\n- [x] I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue\n\n### Description\n\nOn current `main` (v2, tested at 3a6f2996), when a caller supplies its own request id via `CallOptions[\"request_id\"]` (added in #3046), the dispatcher's minted-id sequence can later land on that same id after the supplied request completes. The session then sends two different requests with the same id, which the spec forbids:\n\n\u003e The request ID MUST NOT have been previously used by the requestor within the same session.\n\n(https://modelcontextprotocol.io/specification/2025-11-25/basic#requests, same wording since 2025-03-26. The SDK pins this itself as `protocol:request-id:unique` in `tests/interaction/_requirements.py`: \"ids are never reused within the session\".)\n\n## Root cause\n\nIn `JSONRPCDispatcher.send_raw_request` (`src/mcp/shared/jsonrpc_dispatcher.py`, around line 338):\n\n```python\nelse:\n    # Mint past any key a supplied id occupies: the collision error is\n    # reserved for the caller who actually chose the id.\n    request_id = self._allocate_id()\n    while request_id in self._pending:\n        request_id = self._allocate_id()\n```\n\nThe comment says minting should skip past any supplied id, but the guard only checks `self._pending`, and pending entries are popped when a request completes (line ~428). So for a supplied integer id (or numeric string, since `coerce_request_id` folds `\"2\"` and `2` into one key): once that request finishes, the monotonic counter eventually reaches the same value and reuses it on the wire.\n\n`DirectDispatcher._dispatch_request` (`src/mcp/shared/direct_dispatcher.py`, around line 253) has the same pattern with `self._in_flight_ids`, which is discarded in the `finally`.\n\n## Why it matters\n\nThe receiving side is allowed to assume per-session id uniqueness. The SDK's own stateful Streamable HTTP server already mishandles duplicate ids (#3060, response cross-wiring), so an innocent client that supplies small integer ids for a few calls and then keeps using the same session can hit that server-side behavior through no fault of its own. The SDK-internal user of this feature (the `subscriptions/listen` driver's `\"listen-N\"` ids) is immune because non-numeric string ids never collide with the minted integer sequence, so this only bites users of the new public `CallOptions[\"request_id\"]` with integer or numeric-string ids.\n\nNote this is only about the dispatcher's own minting crossing a completed supplied id. The reverse direction (a caller re-supplying an id it already used before) is currently allowed on purpose and asserted by tests, so I left that alone.\n\n## Proposed fix\n\nWhen accepting a supplied id, advance the mint counter past its coerced key so minted ids can never revisit it:\n\n```python\n# jsonrpc_dispatcher.py, after computing pending_key for a supplied id:\nif isinstance(pending_key, int):\n    self._next_id = max(self._next_id, pending_key)\n```\n\nand the same in `direct_dispatcher.py` with `in_flight_key`. Happy to open a PR with regression tests for both dispatchers if this looks right.\n\n### Example Code\n\n```python\nimport anyio\nfrom mcp_types import JSONRPCRequest, JSONRPCResponse\n\nfrom mcp.shared.jsonrpc_dispatcher import JSONRPCDispatcher\nfrom mcp.shared.message import SessionMessage\n\n\nasync def main() -\u003e None:\n    c2s_send, c2s_recv = anyio.create_memory_object_stream[SessionMessage | Exception](4)\n    s2c_send, s2c_recv = anyio.create_memory_object_stream[SessionMessage | Exception](4)\n    client = JSONRPCDispatcher(s2c_recv, c2s_send)\n\n    async def on_request(ctx, method, params):\n        return {}\n\n    async def on_notify(ctx, method, params):\n        pass\n\n    wire_ids = []\n\n    async def respond() -\u003e None:\n        async for wire in c2s_recv:\n            if isinstance(wire, SessionMessage) and isinstance(wire.message, JSONRPCRequest):\n                wire_ids.append(wire.message.id)\n                await s2c_send.send(\n                    SessionMessage(JSONRPCResponse(jsonrpc=\"2.0\", id=wire.message.id, result={}))\n                )\n\n    async with anyio.create_task_group() as tg:\n        await tg.start(client.run, on_request, on_notify)\n        tg.start_soon(respond)\n\n        await client.send_raw_request(\"ping\", None, {\"request_id\": 2})\n        await client.send_raw_request(\"ping\", None)\n        await client.send_raw_request(\"ping\", None)\n\n        tg.cancel_scope.cancel()\n\n    print(\"wire request ids in order:\", wire_ids)\n    # prints: wire request ids in order: [2, 1, 2]\n    # the third request (dispatcher-minted) reuses the completed supplied id 2\n\n\nanyio.run(main)\n```\n\n### Python \u0026 MCP Python SDK\n\n```\npython: 3.14.5\nmcp: main @ 3a6f2996 (v2 development line)\n```\n\n---\n\nAI disclosure, since it's policy here: I leaned on Claude Code to help navigate the codebase and pressure-test this analysis, but I ran and verified the repro myself and I understand the fix I'm proposing. Freshman in college trying to contribute something genuinely useful, so if I've misjudged the intent behind the mint loop I'd honestly love the correction :)\n","author":{"url":"https://github.com/ayaangazali","@type":"Person","name":"ayaangazali"},"datePublished":"2026-07-18T11:00:46.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/3126/python-sdk/issues/3126"}