[namtran1812]

Fixes #3791

Summary

Long-lived requests can fail after repeated productive SSE reconnects because _handle_reconnection() recursively awaits itself, accumulating Python stack frames.

In a deterministic reproduction, each connection delivers a notification with a new event ID before closing. At the default recursion limit, the client fails after approximately 970 connections with CONNECTION_CLOSED and “reconnection attempts were exhausted,” before the final response arrives. Raising the recursion limit allows the same scenario to complete all 1,500 connections.

Replace recursive reconnection with an iterative loop so productive resumptions can continue without accumulating stack frames.

Changes

• Replace recursive calls with a loop carrying the current event ID, retry delay, and attempt count.
• Exit each response context before opening the next connection.
• Preserve existing retry accounting, resumption-token callbacks, cancellation, and terminal error handling.
• Add a regression covering 1,500 connections, ordered delivery of 1,499 notifications, resumption cursors, and the final response without modifying Python’s recursion limit.

This addresses stack growth separately from the no-progress retry-budget behavior tracked in #2393 and proposed in #2395.

Validation

• Confirmed the new regression fails on unmodified code and passes with this change.
• macOS / Python 3.13: all 120 transport tests passed.
• Linux / Python 3.12: full suite passed—6,227 passed, 8 skipped, 1 xfailed.
• Coverage: 100%, with strict-no-cover passing.
• Ruff lint, formatting, Pyright, and git diff --check passed.

The reproduction uses a synthetic HTTP peer; this failure has not been verified in a production deployment.

AI assistance

AI assistance was used for investigation, implementation, and validation. I reproduced the failure and ran the transport tests, lint, formatting, and type checks locally.

[github-actions]

This PR has been closed automatically. This repo only keeps pull requests open when they come from a maintainer, or from a contributor a maintainer has assigned to the linked issue, and you aren't currently assigned to #3791.

If a maintainer assigns you to #3791, this PR reopens on its own and there's nothing more you need to do here. Assignment is a maintainer call based on capacity; comments that only ask to be assigned don't factor in. What does help is engaging on the issue itself by confirming the repro, explaining why it matters for your use case, or describing the approach you'd take.

You're welcome to keep pushing commits here (just avoid force-pushing, since GitHub can't reopen a rewritten branch), but that on its own won't get the PR reviewed or the issue assigned, and realistically most auto-closed PRs stay closed. There's no need to open a new PR either way.

CONTRIBUTING.md has the full reasoning, but in short:

• We're a small team with very little capacity to review community PRs right now.
• Many recent PRs are AI-generated with little human review, and reviewing one carefully still costs a maintainer as much time as it ever did. A well-described issue is usually more useful to us than the code.

Maintainers: reopen, remove missing-issue-link, or add bypass-issue-check to override.