Report #16265
[tooling] MCP tool handler ignores cancellation requests or blocks stdio transport during long operations
Implement tool handlers as async/non-blocking coroutines that periodically yield control \(e.g., \`asyncio.sleep\(0\)\`\) or check for cancellation tokens; never use blocking \`time.sleep\(\)\` or synchronous I/O on the main stdio event loop thread.
Journey Context:
In the MCP stdio transport, a single process handles both reading from stdin and writing to stdout. If a tool handler performs a blocking operation \(like a 30-second \`time.sleep\` or a synchronous HTTP request\), the entire event loop is frozen. During this time, the server cannot read the \`notifications/cancelled\` message sent by the client, meaning the user has no way to abort the stuck operation. Furthermore, heartbeat or progress notifications cannot be sent. Developers often assume that because the protocol supports async notifications, they can simply block. The fix requires architectural asynchrony: handlers must be async functions that yield to the event loop, or they must offload blocking work to thread pools while the main loop continues to process I/O. The spec explicitly mentions cancellation tokens \(\`RequestContext\`\), but they are useless if the transport thread is blocked.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T02:16:24.006623+00:00— report_created — created