fix: propagate SSE stream errors to waiting requests

[heyhayes]

Summary

Fixes #1401. Also fixes #1789 (closed as duplicate).

When an SSE read timeout occurs during a StreamableHTTP POST request, the pending send_request call hangs indefinitely. The transport catches the exception but never sends an error back through the read stream, leaving the caller blocked on response_stream_reader.receive() with nothing to receive.

This PR fixes error propagation at the transport level so that SSE stream failures produce a JSONRPCError keyed to the original request ID. BaseSession._handle_response routes it to the correct per-request response stream, and send_request surfaces it as MCPError to the caller. This approach keeps failures isolated to the affected request rather than tearing down the entire session.

What changed

_handle_sse_response now sends a JSONRPCError(INTERNAL_ERROR, "SSE stream ended without a response") when the SSE stream ends without delivering a complete response, whether due to a read timeout, network error, or unexpected server close. If a last_event_id was received, reconnection is attempted first; the error is only sent after reconnection is exhausted.

_handle_reconnection returns bool instead of None so callers can distinguish success (response delivered) from failure (attempts exhausted). The method also fixes an infinite recursion bug: the attempt counter was reset to 0 on every stream end (even when no complete response was delivered), which combined with httpx read timeouts causing graceful stream termination meant the reconnection loop could run forever.

handle_get_stream applies the same fix to the GET stream's reconnection loop: the attempt counter only resets when events were actually received during the connection. Empty connections that close immediately count toward MAX_RECONNECTION_ATTEMPTS.

_default_message_handler now logs a warning for exceptions instead of silently discarding them, providing observability for transport errors not tied to a specific request.

Test plan

• New E2E test: client with 0.5s SSE read timeout reads a slow resource (2s server delay), asserts MCPError is raised instead of hanging
• New unit test: _handle_reconnection returns False when called at max attempts
• All 51 existing streamable HTTP tests pass (including reconnection, polling, and multi-reconnection tests)
• All 233 client tests pass
• Linting (ruff check .) and type checking (pyright) clean

[fengjikui]

I took a pass at refreshing this because the current PR is marked conflicting, and this issue is still referenced from #1401 by downstream users.

I did not want to open a duplicate PR without checking first, so I rebuilt the same narrow direction on current origin/main here:

• branch: https://github.com/fengjikui/python-sdk/tree/codex/rebuild-pr2122-sse-error-propagation
• commit: 684e38b (fix: propagate streamable HTTP SSE errors)
• touched files: src/mcp/client/session.py, src/mcp/client/streamable_http.py, tests/shared/test_streamable_http.py

Validation run locally on the refreshed branch:

uv run pytest tests/shared/test_streamable_http.py::test_server_close_sse_stream_via_context 
  tests/shared/test_streamable_http.py::test_streamable_http_client_auto_reconnects 
  tests/shared/test_streamable_http.py::test_streamable_http_client_respects_retry_interval 
  tests/shared/test_streamable_http.py::test_handle_reconnection_returns_false_on_max_attempts 
  tests/shared/test_streamable_http.py::test_sse_stream_close_raises_when_reconnection_fails -q
# 5 passed

uv run ruff check src/mcp/client/streamable_http.py src/mcp/client/session.py tests/shared/test_streamable_http.py
# All checks passed

uv run ruff format --check src/mcp/client/streamable_http.py src/mcp/client/session.py tests/shared/test_streamable_http.py
# 3 files already formatted

git diff --check origin/main..HEAD
# clean

The refreshed patch keeps the original behavior intent: _handle_reconnection() returns whether a response was delivered, _handle_sse_response() sends a JSONRPC error back to unblock the pending request when reconnection cannot deliver the response, empty GET SSE streams count toward the reconnect budget, and the default message handler logs otherwise-unhandled exceptions.

Happy to either open this as a refresh PR against main, or leave the branch here for @heyhayes / maintainers to cherry-pick if that is preferred.