Productive SSE reconnects accumulate stack frames and eventually fail #3791

Problem

Repeated productive SSE resumptions eventually fail because _handle_reconnection() recursively awaits itself.

I reproduced this on current main at d7845c07, using an in-memory HTTP transport. Every connection delivers a notification with a new event ID before closing; connection 1,500 supplies the final JSON-RPC response.

On macOS with Python 3.13:

• Default recursion limit: 972 HTTP requests, 970 delivered notifications, then CONNECTION_CLOSED with “reconnection attempts were exhausted.”
• Recursion limit raised to 3,000: all 1,500 requests complete, delivering 1,499 notifications and the final response.

The higher recursion limit is only a diagnostic experiment.

Expected behavior

Productive resumptions should continue without accumulating Python stack frames or failing because of the interpreter recursion limit.

Scope

This differs from #2393’s no-progress retry-budget problem: every reconnect here delivers new data and advances the event ID.

PR #3790 contains a proposed iterative implementation and a deterministic regression test. The test fails on unmodified code and passes with the patch, without changing the recursion limit. The proposed change preserves existing retry accounting.

The reproduction uses a synthetic peer; I have not verified this failure in a production deployment.

Would an iterative implementation preserving the current retry semantics be an acceptable scope for this issue?

AI assistance was used for investigation and implementation. I reproduced the behavior and ran the transport tests and static checks locally.