fix(client-runtime): keep healthy sessions on their current route#25526

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — This PR changes shared client-runtime connection policy by preventing healthy sessions from being replaced during route discovery, while preserving ranked-route selection for necessary reconnects. Because it changes when socket replacement and resynchronization occur across multiple clients, the policy warrants human review.

^{You can add or adjust custom eligibility rules. Learn more.}

Review in Change Stack →

No actionable comments were generated in the recent review.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

Thread transfer impact

⚠️ The latest CI run did not produce a thread transfer result for 35753a4.

This comment will update automatically after the next completed run.

Verified in a real dev environment

verified as-is at 35753a4d77829c80914ac0b0e7f8250851b5108d on a disposable linux boat vm. no source changes or pushes.

• installed and ran github/main (c677d5fc45) in /home/user/main, then stopped it before running the exact pr head. ran vp i in both checkouts. only one dev server ran at a time, using isolated .t3 state. actual ports were web 8693 and server 16733.
• used repository playwright with /usr/bin/google-chrome. paired two addresses through settings, added /home/user/route-qa as a project through the app, and created threads and real codex gpt-6.1-sol turns through the composer. the web client used its hosted-app mode so both saved bearer routes went through the production registry, resolver, driver, authentication, websocket, subscriptions, and orchestration.
• two transparent local network proxies forwarded to the same real dev server. preferred 18081 answered real discovery/auth/pairing but rejected websocket upgrades; fallback 18082 worked. this injected a transport failure, with no mocked app responses, fixtures, or replay provider.
• main reproduced the bug during a real 90-second terminal turn: at 09:46:01.406Z it closed the healthy fallback socket, attempted the failing preferred websocket, then opened another fallback socket. settings visibly changed from connected to connecting. the provider turn still completed, so the reproduced defect is unnecessary socket replacement and resynchronization, not loss of the provider process.
• the pr kept the fallback socket opened at 09:49:23.576Z until an intentional transport drop at 09:51:49.134Z. there were no intermediate websocket closes or preferred websocket attempts across the periodic-check interval and the real 90-second turn. the response was CONTINUITY_OK.
• after making the preferred route work, the healthy fallback stayed connected. an intentional socket drop reconnected through preferred 18081 at 09:51:52.189Z, while a second real terminal turn was running. that turn returned RECONNECT_OK. a client reload used the saved preferred route, and a new composer turn returned FOLLOWUP_OK.
• neighboring behavior: switching the environment off disconnected it and removed its projects; switching it on restored the fallback connection and projects. a repeated transport drop then selected the working preferred route, shown in the recording below.
• blacksmith ran the existing supervisor, registry, route-selection, and rpc-session files: 111 tests passed across 4 files. the github aggregate Check passed; the live rollup has 24 successes, 6 skips, 1 neutral result, and 1 cancelled native-fingerprint run alongside successful runs of that check. no new test files were created.

short transport transcript (utc):

before, main unnecessarily reconnects:

main: healthy fallback changes from connected to connecting and back

after, the pr retains the fallback connection beyond the route-check interval:

pr: fallback remains connected while the preferred websocket is unavailable

neighboring behavior, off/on followed by intentional transport loss and recovery on the preferred route:

pr: environment off and on works, then socket loss selects the working preferred route

real provider results after continuity, reconnect, and client reload:

codex gpt-6.1-sol returns continuity, reconnect, and follow-up results in the real client

all captures were inspected. uploaded videos played to completion and seeking worked in t3's browser player.

Not verified

physical lan/tailscale transitions, hosted t3 connect relay and dpop renewal, long native background suspension, packaged electron, macos/windows, and native ios/android were not exercised on this linux vm. the runtime failure injected here was websocket upgrade rejection; the separate initial-config/synchronization failure is covered by the passing existing regression tests, not a real-network run. automatic learned-route insertion was not exercised; these routes were paired and reordered through settings. no claim is made about other providers. maintainer approval of the route policy remains separate from verification.

Superseded by #26757, which folds in the route rule: a healthy session keeps its route until the next reconnect. You are credited with a Co-authored-by trailer. Closing this so the two don't conflict.