Handle connection errors in StreamableHTTP post_writer - #2282
Closed
omar-y-abdi wants to merge 5 commits into
Closed
Handle connection errors in StreamableHTTP post_writer#2282omar-y-abdi wants to merge 5 commits into
omar-y-abdi wants to merge 5 commits into
Conversation
Copy link
Copy Markdown
Sorry, something went wrong.
When _handle_post_request or _handle_resumption_request raises (e.g. server unreachable), the exception propagated into the task group and tore down the entire transport, causing an infinite cancellation retry loop with sustained high CPU use. Wrap handle_request_async in try/except so connection errors are forwarded to the read stream as Exception objects. The client session can then handle them normally instead of crashing. Reported-by: slykar
9 tasks
When a JSONRPCRequest fails with a connection error in post_writer, the error must be sent as a JSONRPCError wrapped in a SessionMessage so the response router in BaseSession can match it to the waiting send_request call. Sending a raw Exception causes the request to hang indefinitely because _receive_loop forwards it to _handle_incoming (a no-op by default) while send_request blocks on its response stream. Notification errors are still forwarded as raw exceptions since nothing waits on a response stream for them.
For notification connection errors, log a warning and continue rather than forwarding a raw Exception to the read stream (where it would be silently ignored by _handle_incoming anyway). This keeps the post_writer loop alive and achieves 100% coverage. Also move contextlib.suppress inside the request branch — we only need to suppress errors from the JSONRPCError construction/send, not from the isinstance check itself.
Copy link
Copy Markdown
Contributor
|
Thanks for your contribution! Closing this in favour of #2124 as that predates this PR. |
Sorry, something went wrong.
This was referenced Apr 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2273.
Fixes #2110
When the server becomes unreachable mid-session, _handle_post_request raises a connection error (e.g. httpx.ConnectError). Without this fix, the exception propagates into the anyio task group and tears down the entire transport, causing an infinite cancellation retry loop with sustained high CPU use.
This wraps handle_request_async in a try/except that catches Exception (re-raising cancellation) and forwards the error to the read stream via read_stream_writer.send(exc). The client session then receives it as a normal error instead of crashing. This is the same approach used elsewhere in the transport (e.g. the outer post_writer catch).
Includes a test that connects to a dead port, sends a request, and verifies the connection error is forwarded to the read stream.