fix(KNO-13857): reduce websocket reconnect load when connections can't recover#1031
Conversation
…t recover Escalate the Phoenix socket reconnect backoff toward a 10-minute cap (was a fixed 30s cap that Phoenix reset on every successful open), so a client that can never reconnect - e.g. after an API key rotation leaves stale credentials rejected on every upgrade - settles into a slow retry cadence instead of a tight loop. The escalation survives brief "connect then immediately drop" cycles and resets once a connection stays up for 30s. Also: - teardown() always disconnects the socket, even mid-reconnect, so a reauth that replaces the client can't leak a socket that retries forever. - Hidden background tabs stop retrying: a socket mid-reconnect when the page is hidden is disconnected, not just connected ones, and resumes on visible. - Reconnect promptly on the browser `online` event so recovery after a real network drop doesn't wait out the longer backoff.
🦋 Changeset detectedLatest commit: 1ba423c The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit b6bb977. Configure here.
Addresses comment by @cursor: the `online` handler could revive a socket that was cleanly/deliberately disconnected. Gate it on whether Phoenix wants to reconnect (unclean drop or failed attempt), read from the close event's `wasClean`, instead of on whether the socket was ever active.
Adds tests for the three handleOnline early-returns (no socket, already connected, page hidden) that Codecov flagged as missing patch coverage.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1031 +/- ##
==========================================
+ Coverage 64.49% 64.71% +0.21%
==========================================
Files 212 212
Lines 10217 10275 +58
Branches 1389 1406 +17
==========================================
+ Hits 6589 6649 +60
+ Misses 3603 3601 -2
Partials 25 25
|

Description
Fixes KNO-13857 (follow-up to INC-408).
A customer rotated their public API key; their deployed clients kept the old one. Every websocket reconnect got a
403that could never succeed, so each client retried forever — fleet-wide that was a ~1000% spike that saturated the sockets pods. The SDK can't stop a bad key, but it shouldn't turn one into a firehose. Three changes inpackages/clientfix that:ApiClientso it survives the brief "open then drop" cycles that used to reset it. A dead connection settles to ~1 try / 5 min; the first ~6 attempts are unchanged, so real blips still recover fast.teardown()always disconnects (even mid-retry), so a token refresh can't leave an old socket retrying forever with dead credentials.Plus an
onlinelistener that reconnects immediately when the network returns, so the longer backoff doesn't strand real users.Result: a stuck tab drops from ~401 reconnects to ~29 (foreground) / ~6 (hidden) over the incident window — a ~14–46× fleet reduction that turns the incident's +1000% into +27–71%. (Applies to clients that upgrade and redeploy.)
Checklist
Covered in
test/api.test.tsandtest/pageVisibility.test.ts. Full client suite (582 tests),type:check,lint, andformat:checkpass.