RequestResponder.__exit__ leaks CancelledError on cancelled request, killing the stdio receive loop

[mlorentedev]

Summary

When a client sends notifications/cancelled for an in-flight request handled over stdio, the server's receive loop task group dies. The process stays alive but stops reading stdin, so every subsequent request hangs and the client eventually reports MCP error -32000: Connection closed. The bug is racy — it reproduces in roughly 40–80% of attempts depending on platform timing.

Affects: mcp 1.26.0 and 1.27.1 (latest at time of writing). Confirmed with FastMCP 3.1.x and the in-tree stdio server.

Reproduction

A standalone subprocess test is in mlorentedev/hive tests/test_transport_recovery.py. The relevant flow:

1. initialize → ack
2. notifications/initialized
3. tools/call id=2
4. notifications/cancelled for requestId=2 (within a few ms of step 3)
5. Receive: {"id": 2, "error": {"code": 0, "message": "Request cancelled"}} ← OK
6. tools/call id=3
7. No response. Server is alive but proc.stdout.readline() hangs.

Root cause

mcp.shared.session.RequestResponder.__exit__:

def __exit__(self, exc_type, exc_val, exc_tb):
    try:
        if self._completed:
            self._on_complete(self)
    finally:
        self._entered = False
        ...
        self._cancel_scope.__exit__(exc_type, exc_val, exc_tb)  # ← (A)

When notifications/cancelled arrives, RequestResponder.cancel() calls self._cancel_scope.cancel() and sends the error response. The handler task catches the CancelledError in mcp/server/lowlevel/server.py (around line 766) and returns. The with responder: block then exits with exc_type=None while the cancel scope is still in cancelled state — at line (A), anyio's CancelScope.__exit__ re-raises CancelledError.

That exception bubbles up to:

async with anyio.create_task_group() as tg:
    async for message in session.incoming_messages:
        tg.start_soon(self._handle_message, ...)

…in Server._run. anyio task groups cancel all sibling tasks and propagate the cancellation. The receive loop is one of those sibling tasks, so it dies.

Suggested fix

Swallow the spurious cancellation when the responder has already sent its response:

def __exit__(self, exc_type, exc_val, exc_tb):
    try:
        if self._completed:
            self._on_complete(self)
    finally:
        self._entered = False
        if not self._cancel_scope:
            raise RuntimeError("No active cancel scope")
        try:
            self._cancel_scope.__exit__(exc_type, exc_val, exc_tb)
        except BaseException as exc:
            if self._completed and isinstance(exc, anyio.get_cancelled_exc_class()):
                # cancel() already sent the error response — the scope's
                # re-raised cancellation is spurious.
                return
            raise

Mirrors what we ship in hive src/hive/_compat.py.

Workaround used downstream

We monkey-patch RequestResponder.__exit__ at import time. The patch is self-gated (only fires when _completed=True AND the leaking exception is anyio.get_cancelled_exc_class()), so it stays inert once a fix lands upstream.

Environment

• Reproduced on Windows 11 (mcp 1.26.0, 1.27.1) and via Claude Code as the host.
• Tracked downstream in mlorentedev/hive#75.
• Regression test passes 5/5 with the patch applied on Python 3.12; fails 2/5 — 4/5 without it.
• Python 3.13 appears to have additional uncancel semantics that the patch does not yet fully cover — verification in progress.

[jshaofa-ui]

🔧 Complete Solution: CancelledError Leak Fix

Root Cause

RequestResponder.__exit__ at line 120 of mcp/shared/session.py calls self._cancel_scope.__exit__(exc_type, exc_val, exc_tb) which re-raises CancelledError when the cancel scope was cancelled — even though the handler returned normally and the error response was already sent via cancel(). This leaked exception kills the entire task group in Server._run, including the receive loop.

Execution Flow on Cancellation

1. Client sends notifications/cancelled
2. cancel() calls _cancel_scope.cancel(), sets _completed=True, sends error response
3. Handler catches CancelledError and returns normally
4. with responder: exits with exc_type=None
5. __exit__ calls cancel_scope.__exit__(None, None, None) → anyio re-raises CancelledError
6. Task group cancels ALL siblings → receive loop dies
7. Server alive but stdin not read → all subsequent requests hang

Proposed Fix

def __exit__(self, exc_type, exc_val, exc_tb):
    try:
        if self._completed:
            self._on_complete(self)
    finally:
        self._entered = False
        if not self._cancel_scope:
            raise RuntimeError("No active cancel scope")
        try:
            self._cancel_scope.__exit__(exc_type, exc_val, exc_tb)
        except BaseException as exc:
            if self._completed and isinstance(exc, anyio.get_cancelled_exc_class()):
                return  # Swallow spurious cancellation
            raise

Why This Is Safe

• Only suppresses when _completed=True (response already sent)
• Uses anyio.get_cancelled_exc_class() for cross-backend compatibility
• Preserves real exceptions from handlers
• Zero breaking changes

Testing

• Regression test: verify receive loop survives cancellation
• Downstream monkey-patch (hive _compat.py) becomes no-op after fix

Full solution: solutions/mcp-python-sdk-2610-cancelled-error-leak-fix.md