fix(client): propagate SSE POST errors to caller instead of hanging (#2110)

[fede-kamel]

Summary

Fixes the remaining client-side hang from #2110, in sse_client.

_send_message (the message-POST coroutine) called response.raise_for_status() with no handler. On a non-2xx (401/403/404/5xx) or a network error, the exception propagated into the post_writer task group and was swallowed by its except Exception: logger.exception("Error in post_writer"). The failure never reached the read stream, so a caller blocked on read_stream.receive() — e.g. ClientSession.initialize() — hung forever.

The fix catches httpx.HTTPError inside _send_message and forwards it to read_stream_writer, the pattern stdio.py and websocket.py already use, and that streamable_http.py uses for its >= 400 responses. The caller now receives the error promptly.

Scope note

This PR was originally broader. Since it was opened, main independently landed the equivalent fix for streamable_http_client (the status_code >= 400 branch in _handle_post_request now sends a JSONRPCError to the read stream with data={"http_status": ...}). That half is therefore dropped here — this is rebased on current main and scoped to the one remaining swallow path: sse_client. It's also distinct from #2340, which addresses the sse_reader/connection path rather than the message-POST path.

Verification

• New regression test test_sse_client_post_error_propagates_to_caller: drives a real SSE handshake whose message POST returns 503 and asserts the caller receives the HTTPStatusError via the read stream within a bounded timeout.
• Negative control: the test times out (fails) against the unpatched client, and passes with the fix — confirming it reproduces the hang.
• ./scripts/test: full suite green, 100.00% coverage (branch), strict-no-cover clean.
• ruff format / ruff check / pyright: clean.

Closes #2110.

[fede-kamel]

Hi @Kludex @felixweinberger — friendly ping for review. This fixes #2110 (HTTP transport swallowing errors → client hangs). The fix is small (~50 LOC of behavior change), and there's a substantial test suite to back it: 10 substantive tests including a negative control where I reverted the fix and confirmed all 10 hang against unpatched main. CI green, no conflicts.

cc @chriscasola since you reported the original issue — happy to get any input.

Would really appreciate getting a reviewer assigned when there's bandwidth. Thanks!

[fede-kamel]

Hey @maxisbey — could I get your eyes on this? You filed #2110 originally; this PR propagates the swallowed httpx errors (the root cause flagged in the issue) and preserves the HTTP status in ErrorData.data.

Just rebased onto current main (clean, no conflicts with #2560's SSEError import refactor) and re-ran the full tests/shared/test_sse.py + tests/shared/test_streamable_http.py suite locally — 99 passed, including the network-error regression guard. ~50 LOC of behavior change with 10 substantive tests + negative control.

Happy to backport to v1.x if useful — saw the recent [v1.x] activity. Closes #2110.

[fede-kamel]

Hi @maxisbey, @Kludex, @felixweinberger — would love your eyes on this when you have a moment 🙏

This PR takes a fresh swing at #2110 (HTTP transport swallowing non-2xx status codes and hanging the client). Current state:

• ✅ All 25 CI checks green — full test matrix across Python 3.10–3.14 on Ubuntu and Windows, plus client/server conformance and pre-commit.
• ✅ Rebased on main, no conflicts, ready to merge.

Happy to iterate on anything — feedback very welcome, and thank you all for your work on this SDK!