Uh oh!
There was an error while loading. Please reload this page.
fix(client-runtime): tolerate transient foreground probe timeouts - #8522
fix(client-runtime): tolerate transient foreground probe timeouts#8522Radu028 wants to merge 1 commit into
Conversation
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This is a small, localized client-runtime bug fix that preserves a desktop/web session through one transient foreground probe timeout and reconnects after two consecutive timeouts. Tests cover the timeout sequence and reset behavior, while mobile and other connection paths remain unchanged. You can add or adjust custom eligibility rules. Learn more. |
Dismissing prior approval to re-evaluate 5aa6ec6
5aa6ec6 to
6ace61aCompareThe supervisor no longer replaces a live desktop or web session after a single foreground probe timeout. It reconnects after two consecutive timeouts, and a successful probe resets the count. Consecutive stalls mark the wake probe as failed before reconnecting, so the existing skip-backoff behavior is preserved. Mobile resume probes are unchanged. Fixespingdotgg#7231 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
6ace61a to
97442adCompare
What Changed
The connection supervisor no longer replaces a live desktop or web session after a single foreground health probe timeout. It reconnects only after two consecutive timeouts, and a successful probe resets the count. When it does reconnect, it still skips the first backoff rung, the same as a definite probe failure. Definite probe failures and the mobile resume probe are unchanged.
Why
Under temporary host load, one slow probe (15s) tore down an otherwise healthy WebSocket, showed "Failed to connect. Reconnecting..." and disabled the composer while the same host was still stalled.
Fixes#7231. Same approach as #5198, which no longer applies to
main.Verification
vp test run packages/client-runtime/src/connection/supervisor.test.ts(36 passed; covers single-timeout tolerance, reconnect on the second timeout, and reset after a successful probe)Checklist
Built with Claude Fable 5.1 in Claude Code.
Note
Medium Risk
Changes connection recovery timing for desktop foreground probes (up to ~30s before reconnect on hung probes) in a core client-runtime path, though definite failures and mobile probes are unchanged.
Overview
Desktop/web foreground health checks no longer tear down a live session on a single 15s probe timeout.
EnvironmentSupervisornow requires two consecutive stalledapplication-activeprobes before treating the transport as dead and reconnecting (with the same immediate retry behavior as a definite probe failure). A probe that completes successfully resets the timeout counter, and the first timeout only emits a warning while keeping the existing session.Mobile
application-active-probebehavior is unchanged: timeouts still fail fast on the shorter 3s window. Tests were expanded to cover single-timeout tolerance, reconnect on the second timeout, and counter reset after a successful probe.Reviewed by Cursor Bugbot for commit 6ace61a. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Tolerate transient foreground probe timeouts in
EnvironmentSupervisorAdds
FOREGROUND_PROBE_TIMEOUTS_BEFORE_RECONNECT(set to 2) so the desktop foreground probe tolerates a single timeout before forcing a reconnect. A successful probe resets the timeout counter. Mobile explicit foreground probes (application-active-probe) still fail fast on timeout.foregroundProbeTimeoutCountlogic in supervisor.ts.Macroscope summarized 97442ad.