René's URL Explorer Experiment

Title: fix: cancel in-flight handlers when transport closes in server.run() by maxisbey · Pull Request #2306 · modelcontextprotocol/python-sdk · GitHub

Open Graph Title: fix: cancel in-flight handlers when transport closes in server.run() by maxisbey · Pull Request #2306 · modelcontextprotocol/python-sdk

X Title: fix: cancel in-flight handlers when transport closes in server.run() by maxisbey · Pull Request #2306 · modelcontextprotocol/python-sdk

Description: When the transport closes mid-request, server.run() now cancels in-flight handlers instead of waiting for them. Motivation and Context Discovered while investigating #2231. That issue's stated symptom (server survives parent death with no tool running) does not reproduce — stdin EOF propagates cleanly through anyio.wrap_file + TextIOWrapper on all tested Python versions (3.10–3.14). But the investigation surfaced a real adjacent bug: When stdin closes while a tool handler is running, server.run()'s task group joins on the handler rather than cancelling it. The handler eventually finishes, tries to send its response through a _write_stream that _receive_loop already closed, and server.run() crashes with ClosedResourceError wrapped in a triple-nested ExceptionGroup. In practice: a stdio server with a 3-second tool gets SIGTERM'd at 2s by the client's graceful-shutdown escalation (PROCESS_TERMINATION_TIMEOUT), so finally blocks never run. With this fix, the handler gets CancelledError immediately and cleanup runs. This is the same bug class as #2257 (merged last week), which fixed one specific write-after-close in _handle_message. This closes the general case. The existing CancelledError catch in _handle_request (added in #1153 for CancelledNotification) now distinguishes the two cancellation sources via message.cancelled — which checks the responder's own cancel scope, set only by responder.cancel(). TG cancellation is an outer scope and doesn't set it. May help some #526 cases, but the long-lived orphans reported there are more consistent with the client never closing stdin (client-side bug). Go SDK has the same wait-then-crash behavior (conn.go:167); C# fixed it in modelcontextprotocol/csharp-sdk#226. How Has This Been Tested? New test in tests/server/test_cancel_handling.py drives server.run() with raw memory streams (can't use InMemoryTransport — it wraps server.run() in its own finally: tg.cancel_scope.cancel() which masks the bug). Fails with TimeoutError on main, passes with fix. Existing test_server_remains_functional_after_cancel covers the CancelledNotification path unchanged. Verified against real subprocess scenario (Python 3.14, kill -9 parent with tool in progress). Breaking Changes None. Handlers already needed to be cancel-safe for CancelledNotification. Types of changes Bug fix (non-breaking change which fixes an issue) New feature (non-breaking change which adds functionality) Breaking change (fix or feature that would cause existing functionality to change) Documentation update Checklist I have read the MCP Documentation My code follows the repository's style guidelines New and existing tests pass locally I have added appropriate error handling I have added or updated documentation as needed Additional context session.py:108 pragma removed: RequestResponder.__exit__ now sees _completed == False when a handler is cancelled before reaching respond(). Note for reviewers: this also affects streamable HTTP when terminate() fires mid-request (stateless mode after handle_request() returns early, or session DELETE). In-flight tools are now cancelled rather than drained. Since they were previously crashing on the closed write stream anyway, this is strictly better.

Open Graph Description: When the transport closes mid-request, server.run() now cancels in-flight handlers instead of waiting for them. Motivation and Context Discovered while investigating #2231. That issue's stated ...

X Description: When the transport closes mid-request, server.run() now cancels in-flight handlers instead of waiting for them. Motivation and Context Discovered while investigating #2231. That issue's sta...

Opengraph URL: https://github.com/modelcontextprotocol/python-sdk/pull/2306

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width