Activity

1. claude

   added

   v2Affects the v2 line (2.x on main)Affects the v2 line (2.x on main)

   v1Affects the v1.x maintenance lineAffects the v1.x maintenance line

   on Oct 3, 2026
2. Ben-Home commented on Oct 5, 2026

   

   Ben-Home

   on Oct 5, 2026

   More actions

   The two exceptions are almost certainly one event, not two, and the ordering tells you where to look.

   ClosedResourceError on the read side followed by Unexpected ASGI message 'http.response.start' sent, after response already completed means the response object was already finalized when a second http.response.start arrived. In a stateful streamable-http server with multiple concurrent clients on one session, the notification/response path in _handle_post_request is racing: two branches both believe they own the response for a given request/notification exchange, or a notification is being answered on a channel that was already closed.

   Two concrete things worth checking in your repro:

   1. Every notification should produce at most one HTTP outcome - either the 202 Accepted (fire-and-forget) or a JSON response, never both, and never on a closed channel. If the handler awaits the notification and also lets the transport emit a response, you get exactly the response.start after completed pair. Audit whether the notification branch returns early after the 202, and whether the response is written through the same send callable that the closed-resource path already released.

   2. The wedge you cannot yet prove is likely the same root cause at a different severity. If a task in the session task group raises ClosedResourceError inside the notification path, whether the group unwinds and replaces the failed task or leaves a slot occupied depends on how the exception propagates through the anyio task group. The "alive and listening but not responding, CPU runnable" state is consistent with a task group that lost a member without failing the group and is now awaiting a task that already died. That matches the transient-vs-wedge split you observed: usually the raise lands inside a live request context and is swallowed; occasionally it orphans a group member.

   A useful discriminator for the wedge: capture a py-spy dump of the stuck process and look for a task parked on a Receive/send on a channel whose counterpart task is gone. If you see that, it confirms the task-group-leak theory and narrows the fix to the notification branch's exception handling.

   The general hardening for stateful streamable-http servers: treat a ClosedResourceError in a notification path as terminal for that exchange (log, return, do not attempt a second write), and make the response completion idempotent - a second http.response.start should be a no-op-and-log rather than an unhandled ASGI protocol violation. We hit the same class in our MCP connector work when a session was torn down mid-notification; the fix was an explicit per-exchange "response claimed" guard so exactly one branch can write.
3. 0xamlab commented on Oct 6, 2026

   

   0xamlab

   on Oct 6, 2026

   More actions

   I reproduced this on current main: sending a notification, then closing the read stream right after the 202 body is emitted, causes writer.send(session_message) at src/mcp/server/streamable_http.py:629 to raise ClosedResourceError; the outer except then calls response(...) again at line 724, producing the second http.response.start after the response completed.

   The race is that the notification branch returns 202 before forwarding to writer, so any concurrent close is indistinguishable from a late failure and the shared error handler tries to send a fresh response on an already-completed ASGI scope. The fix is to guard that post-response write: once the final body frame has gone out, the handler should swallow ClosedResourceError and not emit another response.

   Disclosure: I contribute to thyn-ai/Algenta (open-source agent tooling).
4. maxisbey commented on Oct 6, 2026

   

   maxisbey

   on Oct 6, 2026 – with Claude

   Contributor

   More actions

   Thanks for the detailed write-up, and for checking it against the earlier issues. This is the same bug as #3631, which has a minimal repro, so I'm going to close this one as a duplicate to keep the fix in one place.

   Both exceptions come from a single request rather than two handlers racing. For a notification, the transport sends the 202 first and then forwards the message to the session. If the session's stream has already closed, that raises ClosedResourceError into the catch-all handler, which then tries to send a 500 on a response that has already completed. That second attempt is your Unexpected ASGI message 'http.response.start'.

   That doesn't explain the hang you saw, and I don't want to lose it. If it happens again, especially once #3631 is fixed, please open a new issue with whatever you can capture (a py-spy dump of the stuck process would be ideal).

   _{AI Disclaimer}

   ---

   Generated by Claude Code
5. maxisbey

   closed this as duplicateon Oct 6, 2026
6. Varshith-Kali commented on Oct 6, 2026

   

   Varshith-Kali

   on Oct 6, 2026

   More actions

   I've reproduced this locally and I'd like to take it on — could you assign #3641 to me?

   What's happening: in _handle_post_request's notification branch, the 202 response goes out and then writer.send(session_message) runs. If the session tears down in that window, the send raises ClosedResourceError, and the outer except Exception handler tries to emit a 500 on the already-completed ASGI scope — which Starlette rejects with "Unexpected ASGI message 'http.response.start' sent, after response already completed". That's the exact pair in the report. Worse, the handler's writer.send(Exception(err)) then re-raises on the closed stream, so the pair escapes handle_request as an unhandled ASGI exception on every occurrence.

   My approach: guard the post-202 send against ClosedResourceError/BrokenResourceError. Since the 202 already went out, there is nothing left to report, so the handler drops the notification (debug log) instead of emitting a second response. I have it implemented with regression tests that fail before and pass after the fix — 7/7 in tests/server/test_streamable_http_router.py, with ruff and pyright clean.