René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Deep JSON-RPC request over stdio logs a validation error and leaves the original request pending","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\nWhen the Python SDK stdio server receives an id-bearing JSON-RPC request with a deeply nested `params` object, the server can log a stream validation error and remain alive, but the original request is never completed with either a JSON-RPC result or a JSON-RPC error. I am filing this as a stdio response-completion/robustness issue.\n\nIn the reproduction below, a post-initialization `ping` request first failed receiving a response at depth 256. The server stayed responsive: follow-up shallow pings succeeded, and the process did not exit. The observable problem is that the original request id remains pending until the client-side timeout.\n\nThis also does not appear to be the same response-correlation issue where the server returns an error with `id:\"\"` or another mismatched concrete id. If the parser cannot recover the original request id, a JSON-RPC parse error with `id:null` would be the conventional response. MCP's typed schema models error-response `id` as optional `string | number`, so omitting the id would also be easier to reason about than leaving the request pending. On stdio, I observed an error notification and stderr validation message, but not a JSON-RPC error response frame for the original request id. From a normal JSON-RPC request/response client's perspective, the request remains incomplete.\n\nThe most relevant issue I found is #1333, but it appears to describe a different stdio responsiveness issue: slow message processing can block subsequent input. In this reproduction, the server remains responsive to later shallow pings, while the original malformed/deep request is left pending.\n\nWhen processing the deeply nested stdio request, the server emitted a validation message like this:\n\n```text\nReceived exception from stream: 1 validation error for JSONRPCMessage\nInvalid JSON: recursion limit exceeded\n```\n\nThe server also emitted an MCP logging notification similar to:\n\n```json\n{\"jsonrpc\":\"2.0\",\"method\":\"notifications/message\",\"params\":{\"level\":\"error\",\"logger\":\"mcp.server.exception_handler\",\"data\":\"Internal Server Error\"}}\n```\n\nThat notification shows that the server observed the parser/validation failure, but it does not complete the pending request id.\n\nFor comparison, the Python Streamable HTTP servers did not show this pending-request behavior for the same deeply nested `ping` request. At depth 256 and above, both stateful and stateless HTTP returned a JSON-RPC parse error promptly, for example:\n\n```json\n{\"jsonrpc\":\"2.0\",\"id\":null,\"error\":{\"code\":-32700,\"message\":\"Parse error: recursion limit exceeded ...\"}}\n```\n\nThat HTTP behavior is not what I am reporting here. I am using it only as a baseline: the stdio path leaves the request pending, while the HTTP path returns a bounded parse error.\n\n### Example Code\n\n```Python\n# Run the stdio server, complete a normal initialization phase, then send a deeply nested `ping` request like this:\n\nimport json\n\ndepth = 256\nparams = {\"leaf\": True}\nfor i in reversed(range(depth)):\n    params = {f\"p{i}\": params}\n\nprint(json.dumps({\n    \"jsonrpc\": \"2.0\",\n    \"id\": 900256,\n    \"method\": \"ping\",\n    \"params\": params,\n}))\n\n'''\nExpected: a JSON-RPC result or JSON-RPC error response that completes request id `900256`, or some other documented bounded failure mode.\n\nObserved:\n\nDepth 32:  response returned successfully.\nDepth 64:  response returned successfully.\nDepth 128: response returned successfully.\nDepth 256: no response for the request id within 7 seconds; later shallow ping succeeded.\nDepth 512+: same pending-request behavior; later shallow pings still succeeded.\n'''\n```\n\n### Python \u0026 MCP Python SDK\n\n```Text\n- Python: 3.12.3 on Ubuntu 24.04\n- MCP Python SDK stable release: `v1.27.2` (`62137874ff26dd74d2fea80ff528a7fd9ca7a5e7`)\n- MCP Python SDK `main` snapshot (fetched 2026-06-01): `616476f6927a5c64213ea97bbd36a7466f410775`\n```","author":{"url":"https://github.com/cclabadmin","@type":"Person","name":"cclabadmin"},"datePublished":"2026-06-01T12:48:53.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/2751/python-sdk/issues/2751"}