René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Stateful streamable server calls listRoots() unconditionally on roots/list_changed, blocking a servlet thread until requestTimeout when no roots consumer is registered","articleBody":"# Stateful streamable server calls `listRoots()` unconditionally on `roots/list_changed`, blocking a servlet thread until `requestTimeout` when no roots consumer is registered\n\n## Bug description\n\nWhen a `McpAsyncServer` / `McpSyncServer` uses the streamable HTTP transport\n(`HttpServletStreamableServerTransportProvider`) and a client that advertises\n`capabilities.roots.listChanged` sends a `notifications/roots/list_changed`\nmessage, the server issues a **server→client `roots/list` request** back to the\nclient — even when the application registered **no** `rootsChangeConsumer`.\n\nThe transport handles the incoming notification by **blocking the servlet\n(request) thread** on that round-trip. If the client does not answer `roots/list`\n(many don't — it's a fire-and-forget notification from their side), the thread\nstays parked for the full `requestTimeout` and then fails with a\n`TimeoutException`. Every such notification pins one HTTP worker thread for the\nwhole timeout window; under multiple clients this degrades the server's request\npool.\n\nThis is the **stateful counterpart of the already-merged stateless fix in\n#835**. #835 made `roots/list_changed` a no-op for\n`HttpServletStatelessServerTransport`; the stateful streamable path\n(`McpAsyncServer.asyncRootsListChangedNotificationHandler`) was not touched and\nstill performs the unconditional round-trip — and here it doesn't just log a\nwarning, it blocks a thread.\n\n## Environment\n\n- `io.modelcontextprotocol.sdk:mcp-core` **2.0.0** (also present on `main`)\n- Transport: Streamable HTTP, `HttpServletStreamableServerTransportProvider`\n- Server: `McpServer.sync(...)`, servlet container (Jetty / Tomcat)\n- Client: any client that declares `roots.listChanged` and sends the\n  notification without answering the resulting `roots/list` (e.g. Claude Desktop\n  via `mcp-remote`)\n\n## Root cause\n\n**1. The notification handler calls `listRoots()` unconditionally.**\n\n`McpAsyncServer.prepareNotificationHandlers` substitutes a logging consumer when\nnone is registered (mcp-core 2.0.0, lines 199–201):\n\n```java\nif (Utils.isEmpty(rootsChangeConsumers)) {\n    rootsChangeConsumers = List.of((exchange, roots) -\u003e Mono.fromRunnable(() -\u003e logger\n        .warn(\"Roots list changed notification, but no consumers provided. Roots list changed: {}\", roots)));\n}\n```\n\nand `asyncRootsListChangedNotificationHandler` then calls\n`exchange.listRoots()` regardless (line 317):\n\n```java\nreturn (exchange, params) -\u003e exchange.listRoots()          // \u003c-- always sent, even to log-and-drop\n    .flatMap(listRootsResult -\u003e Flux.fromIterable(rootsChangeConsumers)\n        .flatMap(consumer -\u003e Mono.defer(() -\u003e consumer.apply(exchange, listRootsResult.roots())))\n        ...\n```\n\nSo a `roots/list` request goes out to the client to fetch a value that is only\nlogged.\n\n**2. The streamable transport blocks the servlet thread on the notification.**\n\n`HttpServletStreamableServerTransportProvider.doPost` handles a notification by\n`.block()`-ing (mcp-core 2.0.0, line 505):\n\n```java\nelse if (message instanceof McpSchema.JSONRPCNotification jsonrpcNotification) {\n    session.accept(jsonrpcNotification)\n        .contextWrite(ctx -\u003e ctx.put(McpTransportContext.KEY, transportContext))\n        .block();                                          // \u003c-- request thread parks here\n    response.setStatus(HttpServletResponse.SC_ACCEPTED);\n}\n```\n\n**3. The server→client request times out after `requestTimeout`.**\n\n`McpStreamableServerSession$McpStreamableServerSessionStream.sendRequest`\n(lines 404–412):\n\n```java\nreturn Mono.\u003cMcpSchema.JSONRPCResponse\u003ecreate(sink -\u003e {\n    this.pendingResponses.put(requestId, sink);\n    ...\n    this.transport.sendMessage(jsonrpcRequest, messageId).subscribe(v -\u003e {}, sink::error);\n}).timeout(requestTimeout)                                 // \u003c-- no answer → TimeoutException\n```\n\nBecause `McpServer.sync(...)` defaults `requestTimeout` to 10s (line 945) — and\nhigher if the app raised it — the thread is pinned for that entire window and\nthen logs:\n\n```\nERROR ... HttpServletStreamableServerTransportProvider: Error handling message:\n  java.util.concurrent.TimeoutException: Did not observe any item or terminal\n  signal within 10000ms in 'source(MonoCreate)'\n```\n\n## Steps to reproduce\n\nA stateful streamable `McpServer.sync(...)` on\n`HttpServletStreamableServerTransportProvider` with **no** `rootsChangeConsumer`\nregistered. Endpoint is `/mcp` below.\n\n```bash\n# 1. initialize, declaring roots.listChanged — capture the mcp-session-id from response headers\ncurl -sS -D - -o /dev/null -X POST http://localhost:8080/mcp \\\n  -H 'Content-Type: application/json' \\\n  -H 'Accept: application/json, text/event-stream' \\\n  -d '{\"jsonrpc\":\"2.0\",\"id\":0,\"method\":\"initialize\",\n       \"params\":{\"protocolVersion\":\"2025-11-25\",\n                 \"capabilities\":{\"roots\":{\"listChanged\":true}},\n                 \"clientInfo\":{\"name\":\"roots-repro\",\"version\":\"1.0.0\"}}}'\n\nSID=\u003cmcp-session-id from above\u003e\n\n# 2. complete the handshake\ncurl -sS -X POST http://localhost:8080/mcp \\\n  -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \\\n  -H \"mcp-session-id: $SID\" \\\n  -d '{\"jsonrpc\":\"2.0\",\"method\":\"notifications/initialized\"}'\n\n# 3. open the listening GET SSE stream (REQUIRED — without it the server fails fast\n#    with \"Stream unavailable for session\" instead of stalling)\ncurl -sS -N http://localhost:8080/mcp -H 'Accept: text/event-stream' \\\n  -H \"mcp-session-id: $SID\" \u0026\n\n# 4. the trigger — this POST hangs for the full requestTimeout, then returns 500\ntime curl -sS -X POST http://localhost:8080/mcp \\\n  -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \\\n  -H \"mcp-session-id: $SID\" \\\n  -d '{\"jsonrpc\":\"2.0\",\"method\":\"notifications/roots/list_changed\"}'\n```\n\nOn the listening stream from step 3 you will see the server push a\n`{\"method\":\"roots/list\",...}` request; nobody answers it, and step 4 blocks for\n`requestTimeout` seconds.\n\n## Expected behavior\n\n`notifications/roots/list_changed` should be acknowledged (202) promptly. When\nno `rootsChangeConsumer` is registered, the server should **not** send a\n`roots/list` request at all — there is nothing to deliver the result to. This\nmatches the stateless behavior already merged in #835.\n\n## Actual behavior\n\nThe server sends `roots/list`, the servlet thread blocks on it, and after\n`requestTimeout` it fails with the `MonoCreate` `TimeoutException` above. One\nHTTP worker thread is consumed per notification for the full timeout.\n\n## Impact\n\n- One pinned HTTP worker thread per `roots/list_changed`, for up to\n  `requestTimeout`; concurrent clients multiply it and degrade the request pool.\n- Recurring `ERROR`-level log noise.\n- Affects every client that declares `roots.listChanged` and doesn't answer the\n  unsolicited `roots/list` — which is spec-legal client behavior.\n\n## Proposed fix\n\nSkip the round-trip when there is nothing to consume — the stateful analog of\n#835:\n\n- In `asyncRootsListChangedNotificationHandler` (or\n  `prepareNotificationHandlers`), only call `exchange.listRoots()` when a real\n  `rootsChangeConsumer` was registered; otherwise treat the notification as a\n  no-op. Don't substitute a logging consumer that forces a client round-trip\n  purely to log the result.\n\nThis also aligns with the direction of #1003 (SEP-2260, \"require server requests\nto be associated with a client request\") and #1012 / #1053 (deprecate roots),\nwhere an unsolicited server→client `roots/list` triggered by a notification is\nbeing designed out of the spec.\n\n## Related\n\n- **#835** (merged) — same fix for the **stateless** transport\n  (`roots/list_changed` → no-op). This issue asks to extend that to the\n  **stateful** streamable path. Its parent #777 is the stateless \"Missing\n  handler\" symptom.\n- **#1003** (SEP-2260) and **#1012 / #1053** — spec work removing/deprecating\n  unsolicited server→client roots requests. Directional, not a current-SDK fix.\n- **#920** and **#1021** — separate streamable-transport robustness issues\n  (session eviction on write failure; CLOSE-WAIT thread exhaustion). Distinct\n  root causes, mentioned only to disambiguate.\n\n## Workaround\n\nA servlet filter in front of the MCP endpoint that answers\n`notifications/roots/list_changed` with `202 Accepted` and drops it, so it never\nreaches the SDK handler.\n","author":{"url":"https://github.com/mayur9991","@type":"Person","name":"mayur9991"},"datePublished":"2026-07-16T05:29:02.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/1061/java-sdk/issues/1061"}