fix(client-runtime): large threads no longer freeze the renderer on every cache save#29446

Problem

The desktop and web renderer freezes for 1.5–2 s every 20–30 s while storage.saveThread Schema-encodes and writes a ~47 MB thread snapshot to IndexedDB on the main thread. This happens even for a thread the user is not viewing. The server sends bounded snapshots, but a mounted thread state adds every streamed event to its projection and never trims it. It saves the whole projection whenever no run is active, and that copy seeds the next mount, so the cache grows without bound. Web keeps every running thread mounted, so a thread running many short turns re-saves after each one. On main the encode alone costs 4 ms at 0.8 MiB, 25–50 ms at 4 MiB and 250–450 ms at 46.6 MiB in Node, in one synchronous step. The renderer adds the IndexedDB write on top.

Change

packages/client-runtime now keeps a thread whose JSON would pass 4 MiB out of the monolithic cache. Threads that loaded older pages are already kept out the same way.

• The size estimate. It adds up string JSON lengths (escapes included) and key overhead without building the document. It is memoized per object in a WeakMap, and projection versions share unchanged rows, so a repeat check only walks new rows. The check runs only once no run is active.
• 4 MiB leaves room for a fresh server snapshot: a 1 MiB turn window plus runs and checkpoints.
• The existing unsaved-thread paths now apply. The scope finalizer writes only queued repairs, and the last bounded saved copy stays as the warm-cache seed.
• An oversized cache already on disk is ignored on load, so the server's bounded snapshot replaces it.
• Every write is checked in persist. A Stop repair that would grow the saved copy past the limit deletes the entry instead of writing it, so stale running rows cannot reload.

Web, desktop and mobile share this code, so all three get the fix.

Scope and approval

Fixes pingdotgg/t3code#29417

Verification

• vp test run packages/client-runtime/src/state/threads-sync.test.ts: 50 passed. The four new cases, with what each fails with on main:
  • does not cache a thread that events grew far past a bounded snapshot (plain text): expected 10336579 to be less than or equal to 4194304
  • … (escaped text): expected 17828139 to be less than or equal to 4194304
  • replaces an oversized cache with a fresh bounded snapshot: expected +0 to be 1, because the oversized cache was used and the server was never asked
  • drops the cache when its repair would pass the size limit: a snapshot of more than 4 MiB was written
• vp run check:changed (format, lint, knip, typecheck of 7 packages, tests): all pass.
• Runtime transcript from a scratch Node driver with a synthetic 2,000-row projection. It times the exact encoder storage.saveThread runs on main, then the new size estimate:

• No visible surface changes, so there are no captures. The driver scripts are not linked because no uploader was available on the VM that did the work.
• Not checked:
  • a profile of the real 30-second cycle in an Electron renderer;
  • the reporter's own Wayland session (the mechanism is in shared client code, not platform code, and the tests above reproduce it);
  • Hermes timings on mobile.

Triaged and fixed by Claude Opus 5.5 (claude-opus-5-5) in Claude Code, running inside T3 Code; reviews by GPT-6.1 Sol (Codex) and Claude Opus 5.5.

🤖 Generated with Claude Code