[core] Retry stream reopen against the reconnect budget#2334
Open
VaguelySerious wants to merge 1 commit into
Open
[core] Retry stream reopen against the reconnect budget#2334VaguelySerious wants to merge 1 commit into
VaguelySerious wants to merge 1 commit into
Conversation
|
Contributor
Addresses review feedback on #2318: a transient failure of the reopen itself (`connect()` throwing inside `reconnect()`) was fatal — only `reader.read()` errors were retried. A brief server unavailability during the reconnect window is exactly the blip this wrapper exists to survive, so count it against the reconnect budget and retry rather than erroring the stream. Budget exhaustion (a server that stays down) still terminates. Adds a test: a reopen that throws once then succeeds recovers transparently. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
VaguelySerious
force-pushed
the
peter/reconnect-budgeted-reopen
branch
from
1ec49b1 to
19a31ce
Compare
Contributor
🧪 E2E Test Results✅ All tests passed Summary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
|
Contributor
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
workflow with 1 step💻 Local Development
▲ Production (Vercel)
workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
workflow with 25 sequential steps💻 Local Development
▲ Production (Vercel)
workflow with 50 sequential steps💻 Local Development
▲ Production (Vercel)
Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
Promise.all with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
Promise.race with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
workflow with 10 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
workflow with 25 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
workflow with 50 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
workflow with 10 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
workflow with 25 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
workflow with 50 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
Stream Benchmarks (includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
stream pipeline with 5 transform steps (1MB)💻 Local Development
▲ Production (Vercel)
10 parallel streams (1MB each)💻 Local Development
▲ Production (Vercel)
fan-out fan-in 10 streams (1MB each)💻 Local Development
▲ Production (Vercel)
SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
❌ Some benchmark jobs failed:
Check the workflow run for details. |
VaguelySerious
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #2318 (now merged), addressing @TooTallNate's review note on it.
#2318's forward-port made object-stream reconnect retry on
reader.read()errors, but a transient failure of the reopen itself —connect()throwing insidereconnect()because the server is briefly unavailable during the reconnect window — was fatal. That's exactly the blip the wrapper exists to survive.This makes the reopen retry against the reconnect budget instead of erroring the stream: each reopen attempt counts against the consecutive-failure cap (and the absolute backstop), so a server that stays down still terminates the stream, but a momentary blip no longer kills it. The cancel/reset of buffered state moves ahead of the retry loop so every attempt resumes from the same frame index.
Test
New case in
reconnecting-framed-stream.test.ts: a reopen that throws once then succeeds recovers transparently (the failed reopen never surfaces to the consumer; resume index is unchanged). All 12 reconnect tests pass.Notes
@workflow/core; user-facing behavior is unchanged (object streams reconnect) — this hardens the path against the blip it targets.🤖 Generated with Claude Code