fix(client-runtime): slow config snapshots no longer drop working connections

[saphid]

Problem

A client gives each connection attempt one 15 second budget. It covers resolving credentials, creating the session, opening the socket and receiving the first config snapshot. When a server is slow to build that snapshot (a cold restart with a large database on a loaded machine), the attempt times out with the socket already open and working. The client tears it down and retries against a server that is no faster, and loops. I saw this loop for about 10 minutes. Fixes #14516.

Change

EnvironmentSupervisor keeps the 15 second budget until the driver reports the synchronizing stage, which is when the session exists and the socket is opening. From then on the attempt has 75 seconds for the socket to open (still capped at 15 seconds by the RPC session) and for the first config snapshot to arrive. Attempts that never reach synchronizing time out after 15 seconds as before. A socket that closes still fails the attempt immediately.

The trade-off: a socket that opens but then never delivers a snapshot is now given up on after up to 90 seconds instead of 15. Web, desktop and mobile share this code.

Scope and approval

Fixes triaged bug #14516. One timeout in packages/client-runtime/src/connection/supervisor.ts. No server, contract or UI changes.

Verification

• New test "keeps a working socket open while a slow server config snapshot arrives": the snapshot arrives 40 seconds into the attempt and the connection is kept. On main the attempt is torn down at 15 s and the connection never reports connected, so the test fails. It passes here.
• "retries when a session never becomes ready" now checks that the attempt survives 74 s after synchronizing and times out at 75 s. It also fails on main.
• vp test run src/connection/supervisor.test.ts in packages/client-runtime: 39 passed. Typecheck, lint and format are clean on the changed files.
• Not exercised in a real client against a slow server.

Implemented and tested by Claude Sonnet 5.5 and Claude Opus 5.5 in Claude Code, running inside T3 Code. Reviewed by GPT-6 Astra.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This changes the default connection lifecycle for all clients, allowing synchronized but not-yet-ready connections to remain active for up to 75 additional seconds. The scope and tests are clear, but the materially longer production timeout warrants human review.

Notes:

• Diff unchanged. Approvability was decided on eligibility alone.

No code changes detected at 592d051. Prior analysis still applies.

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

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 0517fd9b-aac0-4370-afd7-deed35e1b801

📥 Commits

Reviewing files that changed from the base of the PR and between 89237b2 and 8ad513a.

📒 Files selected for processing (2)

• packages/client-runtime/src/connection/supervisor.test.ts
• packages/client-runtime/src/connection/supervisor.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 3 remain after this review.

---

📝 Walkthrough

Walkthrough

The connection supervisor now uses a 15-second timeout to reach synchronization and a separate 75-second timeout after synchronization begins. Tests cover delayed readiness and timeout behavior.

Changes

Connection timeout handling

Layer / File(s)	Summary
Two-phase connection timeout packages/client-runtime/src/connection/supervisor.ts, packages/client-runtime/src/connection/supervisor.test.ts	The supervisor signals when driver progress reaches synchronizing. It applies a 15-second timeout to reach that stage, then allows 75 seconds for synchronization. Tests cover delayed readiness and the updated timeout interval.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: juliusmarminge

Merge Risk: ⚪ Minimal · up to 8ad51

The change lets slow server config snapshots arrive without dropping a working connection, while attempts that never reach synchronization still time out after 15 seconds. No merge-blocking issue was found. The change has not been exercised against a real slow server.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 8ad51

An unresponsive server can keep a connection pending longer, but the wait remains bounded. Readiness and environment-identity checks still precede connection publication, and cancellation remains available.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The increased exposure is longer retention of the existing pending session for each configured connection attempt. The checked paths do not add an entrypoint, transfer authority, or publish a pending lease to connected consumers.

Trust Boundaries and Controls

• observed — Initial configuration must match the prepared connection’s environment identity before readiness succeeds. The driver still awaits that readiness gate before returning the lease, preserving the existing identity-to-session publication boundary.

Resilience and Maintainability Implications

• observed — Establishment continues to race interruption and timeout. Each attempt runs in a scope and clears published lease references on exit; the configuration-subscription task is also scoped. This preserves local failure containment despite the longer wait, without independently proving the socket library’s teardown behavior.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Out of Scope Changes check	⚠️ Warning	The incremental diff also changes .agents/skills/contribution-triage/SKILL.md, .agents/skills/test-t3-app/references/sqlite-fixtures.md, .agents/skills/test-t3-mobile/SKILL.md, `.github/TRIAGE_E…	Remove the unrelated triage, fixture, mobile, exemption-list, and CI changes from this PR. Keep the supervisor timeout change and its regression tests.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the main change: preventing slow config snapshots from dropping working client connections.
Description check	✅ Passed	The description covers the problem, change, scope and approval, and focused verification. It also states the real-client test limitation and identifies the agent models and harness.
Linked Issues check	✅ Passed	Issue #14516 requires the client to keep a working socket while waiting for the first config snapshot. The reported supervisor change keeps the 15-second budget until synchronizing, then allows up t…
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 2…

Full details: Out of Scope Changes check

Explanation

The incremental diff also changes .agents/skills/contribution-triage/SKILL.md, .agents/skills/test-t3-app/references/sqlite-fixtures.md, .agents/skills/test-t3-mobile/SKILL.md, .github/TRIAGE_EXEMPTIONS.td, and .github/workflows/ci.yml. These triage, fixture, mobile, and CI changes have no demonstrated connection to the connection timeout in issue #14516.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Create a new PR

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

Autopilot is currently an internal CodeRabbit preview.

---

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