You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(app): back off event stream reconnects after repeated failures - #48015
The global event stream (server-sdk.tsx) reconnected after every failure with
the same fixed RECONNECT_DELAY_MS delay. This adds an exponential backoff:
a consecutiveErrors counter resets on every successfully consumed event and
increments on each catch;
the reconnect wait becomes min(5000, RECONNECT_DELAY_MS * 1.5 ** min(consecutiveErrors, 8)),
so repeated failures back off from 250 ms up to a 5 s cap, while a healthy
stream keeps the fast cadence.
No other behaviour in the loop changes.
How did you verify your code works?
bun typecheck in packages/app: clean.
The change is a 5-line delta restricted to the reconnect wait; the counter is
scoped to the loop invocation and reset on any received event, so a recovered
stream returns to the fast path immediately.
Been poking at reconnect behavior lately (see #48161 on v2 — client-side backoff, different layer, so no overlap here), so I read through this diff.
Main thing: the consecutiveErrors = 0 at the top of the for-await means a server that accepts the stream, emits a single event and then dies gets the full 250ms base delay again on every cycle, forever. That flapping pattern is basically where backoff earns its keep, so maybe reset the counter only after the stream has stayed healthy for a bit (say N seconds of events) instead of on first event.
Nit: with the 5s cap, the exponent clamp Math.min(consecutiveErrors, 8) can't actually engage at this base — 250ms x 1.5^7 is ~4.3s and anything beyond that hits the cap anyway, so the clamp is dead code unless the base ever drops under ~200ms.
#48014 looks assigned internally, so if this overlaps with planned work no worries — leaving notes in case they're useful.
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
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.
Issue for this PR
Closes #48014
Type of change
What does this PR do?
The global event stream (
server-sdk.tsx) reconnected after every failure withthe same fixed
RECONNECT_DELAY_MSdelay. This adds an exponential backoff:consecutiveErrorscounter resets on every successfully consumed event andincrements on each catch;
min(5000, RECONNECT_DELAY_MS * 1.5 ** min(consecutiveErrors, 8)),so repeated failures back off from 250 ms up to a 5 s cap, while a healthy
stream keeps the fast cadence.
No other behaviour in the loop changes.
How did you verify your code works?
bun typecheckinpackages/app: clean.scoped to the loop invocation and reset on any received event, so a recovered
stream returns to the fast path immediately.
Screenshots / recordings
N/A — not a UI change.
Fork
Checklist