perf(sessions): persist conversation build caches across task re-opens

[arnohillen]

Problem

Clicking a task in the sidebar takes seconds before the transcript renders, even when the session data is already warm in the store. The task detail route fully unmounts on navigation, and the incremental conversation builder (useConversationItems) and thread grouper both live in component-scoped refs, so every re-open falls back to a full O(n) re-parse of the transcript on the main thread. yieldToPaint already documents the mount blocking "for hundreds of ms"; with multi-MB transcripts it is seconds.

Changes

• New conversationDerivedCache module: a small LRU cache (8 tasks per scope, backed by lru-cache, already a workspace dependency via harness) keyed per call site + task that keeps the incremental builder state and thread grouper alive across mounts.
• useConversationItems accepts an optional persist key; without one, behavior is unchanged (per-component ref).
• ConversationView, AcpChatThread, and ChatThreadFooter opt in with distinct scopes (distinct scopes matter: the thread and its footer feed different inputs for the same task, and sharing one builder would make them invalidate each other every render).
• Entries are swept when the session residency system evicts a session's events (or the session is torn down), so the memory reclaim that eviction exists for still works. Entries for tasks that never had a session in the store (e.g. archive surfaces) are exempt from sweeping, so unrelated store commits don't cause rebuild churn.

Warm re-opens (session still in the store) now reuse already-built items: idle sessions return the memoized result identity, and streaming sessions take the append-only fast path because the store keeps appending while the view is unmounted and immer preserves element identity.

How did you test this?

• New unit tests for the cache module: entry persistence, scope isolation, LRU bound, eviction sweep on evictEvents/removeSession, and the no-session exemption (guards rebuild churn on archive surfaces).
• New hook tests: identical result identity across remount with a persist key (idle), completed-turn item reuse across remount while streaming, and unchanged rebuild behavior without a persist key.
• Full @posthog/ui vitest suite: 281 files, 2386 tests passing.
• pnpm typecheck and biome via lint-staged.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

---

Created with PostHog Code

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 39b15a0.}

[greptile-apps]

Comments Outside Diff (1)

1. packages/ui/src/features/sessions/hooks/conversationDerivedCache.ts, line 49 (link)

   LRU counts scopes, not tasks

   MAX_CACHED_TASKS is applied to maps keyed by both scope and task ID, so the three opted-in conversation scopes consume three entries per task. As a result, the build cache retains only about two fully represented tasks instead of eight, causing recently opened tasks to rebuild earlier than the stated cache bound implies.

   Context Used: Do not attempt to comment on incorrect alphabetica... (source)

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: packages/ui/src/features/sessions/hooks/conversationDerivedCache.ts
   Line: 49
   
   Comment:
   **LRU counts scopes, not tasks**
   
   `MAX_CACHED_TASKS` is applied to maps keyed by both scope and task ID, so the three opted-in conversation scopes consume three entries per task. As a result, the build cache retains only about two fully represented tasks instead of eight, causing recently opened tasks to rebuild earlier than the stated cache bound implies.
   
   **Context Used:** Do not attempt to comment on incorrect alphabetica... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))
   
   ---
   
   For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Prompt To Fix All With AI

### Issue 1
packages/ui/src/features/sessions/hooks/conversationDerivedCache.ts:49
**LRU counts scopes, not tasks**

`MAX_CACHED_TASKS` is applied to maps keyed by both scope and task ID, so the three opted-in conversation scopes consume three entries per task. As a result, the build cache retains only about two fully represented tasks instead of eight, causing recently opened tasks to rebuild earlier than the stated cache bound implies.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "perf(sessions): persist conversation bui..." | Re-trigger Greptile}

[arnohillen]

Good catch on the LRU counting scope+task pairs. Fixed in 35a5be0: entries are now grouped per scope with the cap applied inside each scope, so the three conversation scopes no longer shrink the per-task capacity. Added a test asserting a task in one scope survives filling another scope to the cap.