fix: read-idle timeout on SSE so a stalled stream can't hang events()#15
Conversation
A live-events SSE connection that goes silent-but-open (no frames, no keepalive, no close — e.g. a gateway idle timeout on a long job) blocked iterateSse forever. The high-level Job.events() reconnect/poll-fallback only runs when the stream *ends*, so it never recovered — events() hung indefinitely on jobs longer than a few minutes, even though the job itself completed fine (poll/wait/run stayed correct). Add a byte-level read-idle timeout to iterateSse (default SSE_IDLE_TIMEOUT_MS, well above the server's keepalive interval; reset on any bytes, so keepalive comments count as liveness). A stalled stream now errors, which Job.events() already catches and turns into a poll/reconnect. Adds a regression test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 56 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Warning
|
Found running a real >10-minute job against prod: the SSE stream went silent at ~3 min (no frames, no keepalive, no close — a "zombie" connection), and
job.events()hung — still blocked minutes after the job had already completed.poll/wait/runwere unaffected (the job itself finished fine).Root cause
iterateSseread the fetch body with no idle timeout, so it blocks forever on a stalled-but-open connection. The high-levelJob.events()reconnect/poll-fallback only runs when the stream ends (the async iterator returns or throws), which never happens for a zombie →events()hangs.Fix
Add a byte-level read-idle timeout to
iterateSse(defaultSSE_IDLE_TIMEOUT_MS, well above the server keepalive interval). It resets on any bytes — so keepalive comments (whicheventsource-parserdrops as non-messages) still count as liveness, and only a truly silent connection trips it. A stalled stream now errors, whichJob.events()already catches and turns into a poll (terminal?) / reconnect.Tests
Added a regression test: a stream that emits two frames then holds open + silent →
iterateSseerrors quickly (~idle timeout) instead of hanging, after delivering the pre-stall frames. Full suite green; tsc/oxfmt/hygiene clean.🤖 Generated with Claude Code