fix(client): finishing a long background thread no longer freezes the app#33503

Problem

A desktop performance trace showed two main-thread freezes of 1.7s and 1.6s while the user was typing in the composer. The keystrokes queued up and replayed afterwards (16 at once after the first freeze).

Both freezes had the same cause. A thread that had been running in the background finished. runningThreadKeepAliveAtom stopped mounting its live state, the registry removed the atom on the next setTimeout(0), and the thread-state scope finalizer saved the entire live projection to the thread cache in one task:

The JS heap grew by about 300 MB during one save (618 → 915 MB). A thread followed live keeps every item it streams, so the cached copy can reach hundreds of MB. The periodic save after a run settles, and leaving a large thread, run the same code.

#29417 reports the same profile from the periodic save after each settled run: a 47 MB thread re-encoded every 30–50s while the user is in a different thread.

Fixes pingdotgg/t3code#29417

Fix

Thread cache saves now go through makeStoredThreadSnapshotEncoder, built like the existing shell cache encoder (e2b929f):

• It remembers the encoding of each turn item and timeline row, so a re-save only encodes rows that changed.
• It encodes new rows 32 at a time and yields to the host between chunks. Web uses the existing MessageChannel yield.
• It adds up the JSON size as it goes and stops once the rows pass 4M characters. A thread over the cap is not cached, and its older cached copy is removed, so a stale version can't show on reopen. Reopening that thread loads the server's bounded window, the same path threads with expanded history already take.

Because a save now yields, it can finish after a later save of the same thread, a removal, or an environment clear. Each of these takes a ticket when it starts (makeThreadCacheWriteOrder), and a save writes only while no newer ticket exists for its thread or environment, so the newest operation always wins.

The output is byte-identical to the old encoders. Web keeps the full format and mobile the compact one, so no cache schema version changes. The host-yield helper moved to platform/hostYield.ts so both encoders can share it.

Considered and not done:

• Moving the encode to a Web Worker. postMessage structured-clones the projection on the main thread, which costs about as much as the encode it moves, and with the cap the longest remaining slice is about 10ms.
• Storing objects instead of JSON strings in IndexedDB. Once encoding stops blocking, this doesn't help saves, and loading would probably be slower, because JSON.parse beats IndexedDB decoding stored objects on the main thread.

Verification

Benchmark in Node. Each row compares the old one-shot encode with the longest synchronous slice between yields in the new encoder:

• New threadCacheEncoding.test.ts:
  • The full format is byte-identical to the plain schema encode across chunk boundaries, both cold and after items are edited or added.
  • The compact format round-trips.
  • Both formats encode nothing once over the cap.
• New mobile store tests (environment-cache-store.test.ts):
  • A save still encoding doesn't write after a removal, an environment clear, or a newer save. This fails with the ordering check disabled.
  • A thread that grows past the cap has its older cached copy removed.
• Existing web store tests (storage.test.ts, storage.browser.test.ts) and mobile store tests pass.
• vp run check:changed passes.

Screenshots don't apply: nothing visible changes, only main-thread blocking.

Remaining limits

• The renderer heap was already about 600 MB before the first freeze. Threads kept loaded by runningThreadKeepAliveAtom hold their whole live projection in memory. That needs a heap snapshot to investigate and is separate from this change.
• In the full (web) format, each local item is encoded and cached twice: once as a turn item and once inside its timeline row. That memory is bounded by the cap. Building each row from its turn item's cached encoding would roughly halve the work and the memory, and can be a follow-up.
• Each shell update rebuilds savedPullRequestSummariesAtom over every thread shell, about 12ms per update in the trace. Also separate.

🤖 Generated with Claude Code (Claude Opus 5.5)