fix(client): slow servers finish loading the thread list instead of loading it twice

[t3dotgg]

The client gives the shell HTTP load (projects and thread list) 6 s to finish. On timeout, it asks the same server for the same full snapshot over the socket. A slow but alive server then builds the snapshot twice, and the first build is thrown away. A user with about 5,000 threads and 130 projects on T3 Code 0.0.40 (9 days uptime) saw shell loads at p50 7.6 s and max 11.9 s. All 6 of 6 loads were abandoned.

The thread detail loader has the same 6 s limit. A cold thread open loads twice in the same way. "Load earlier" has no socket fallback, so on a slow server it stops at 6 s with no message.

Fix

• Raise DEFAULT_SHELL_SNAPSHOT_TIMEOUT_MS and DEFAULT_THREAD_SNAPSHOT_TIMEOUT_MS from 6 s to 20 s. 20 s covers the reported max of 11.9 s.
• Rewrite the stale "cheaper socket fallback" comments. The socket fallback is not cheaper. It exists for setups where /api fails but /ws works. A dead server is still caught by the socket ping (about 15 to 20 s without a pong), which drops the session and interrupts the shell load and a cold thread open.
• Remove "bounded like the snapshot fetches" from the comment on the 6 s session state timeout, because the two limits are now different.

The socket fallback itself does not change. #5561 chose to request a complete socket snapshot after a failed HTTP load, and that stays.

Tradeoff

If /api hangs but /ws works, the socket fallback now starts after 20 s instead of 6 s. A fast /api failure (404, 403, CORS, connection refused) still falls back at once. Web, desktop, and mobile use the same loaders, so all three get this change. On a slow link, such as a phone on cellular, a large HTTP load now has more time to finish before the client asks for it again over the socket.

Verification

• vp test run packages/client-runtime/src/state/shell.test.ts packages/client-runtime/src/state/shell-sync.test.ts packages/client-runtime/src/state/threads-pagination.test.ts packages/client-runtime/src/state/threads-atoms.test.ts packages/client-runtime/src/state/environmentHttpAuth.test.ts (68 passed)
• vp run --filter @t3tools/client-runtime typecheck
• vp lint and vp fmt on the changed files

No new tests. No test pins the 6 s value, and a test that only checks a constant adds nothing.

Made by Claude Opus 5.5 (1M context) in Claude Code, running in T3 Code.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Increased the default time allowed for shell and conversation snapshots to load from 6 to 20 seconds, reducing premature timeouts when responses are slow.
  • The longer deadline gives snapshot requests more time to complete before fallback or interruption behavior takes effect.

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.5 KiB	13.5 KiB	−10 B (−0.1%)	15.1 KiB	✅
Codex	Thread snapshot wire	7.1 KiB	7.1 KiB	−1 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−9 B (−0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	56.2 KiB	56.2 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	9	9	0 (0.0%)	21	✅
Claude	Total thread wire	13.5 KiB	13.5 KiB	+44 B (+0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.1 KiB	7.1 KiB	−2 B (−0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.5 KiB	+46 B (+0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	57.0 KiB	57.1 KiB	+44 B (+0.1%)	66.4 KiB	✅
Claude	Live turn messages	9	10	+1 (+11.1%)	21	✅

Baseline: 6530de0 · PR result: 139dd4d · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 114.0 KiB
• Claude decoded thread snapshot: 114.7 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes the default timeout for shell and thread snapshot loading from 6 to 20 seconds, affecting fallback timing and the wait for older thread pages. The behavior is narrowly scoped, but product-default changes require human review.

No code changes detected at 139dd4d. 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.

Important

Review skipped

Review was skipped as selected files did not have any reviewable changes.

⚙️ Run configuration

Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: d9e2e1d9-a429-40a1-81c2-7f21bdc47cbe

📥 Commits

Reviewing files that changed from the base of the PR and between 6bb63cc70b01f4cc97fb4c9c7c9902a2fb322a1d and 139dd4d.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

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: Team

Run ID: 6ef7a075-8078-4138-a0e5-7bd55b8dc8c5

📥 Commits

Reviewing files that changed from the base of the PR and between d7b2954 and 6bb63cc70b01f4cc97fb4c9c7c9902a2fb322a1d.

📒 Files selected for processing (1)

• packages/client-runtime/src/state/session.ts

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

---

📝 Walkthrough

Walkthrough

Shell and thread snapshot HTTP timeout defaults increase from 6,000 ms to 20,000 ms. Updated comments describe snapshot fallback and loading behavior. The session-state timeout comment now describes a potentially wedged environment.

Changes

Snapshot HTTP timeouts

Layer / File(s)	Summary
Update timeout defaults and comments packages/client-runtime/src/state/shellSnapshotHttp.ts, packages/client-runtime/src/state/threadSnapshotHttp.ts, packages/client-runtime/src/state/session.ts	The shell and thread timeout defaults increase to 20,000 ms. Comments describe socket fallback, dead-server handling, and cached content while snapshots load. The session-state timeout comment describes a potentially wedged environment.

Priority: ➖ Normal

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

Change: Bug fix

Suggested reviewers: juliusmarminge

Merge Risk: 🔵 Low · up to 6bb63

When /api stalls but /ws works, shell and cold-thread loading may wait up to 14 seconds longer before fallback. The fallback still proceeds, so merging carries a bounded delay risk.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 3 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly identifies the main fix: increasing client load time so slow servers do not load the thread list twice.
Description check	✅ Passed	The description explains the problem, the timeout changes, the fallback behavior, tradeoffs, and verification results. It is focused and sufficiently complete; UI sections are not required because thi…

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

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