perf(sessions): collapse redundant tool_call_update snapshots

[richardsolomou]

Problem

Opening several large tasks balloons renderer memory (2GB+ observed in prod). Agents re-send the full accumulated tool output on every tool_call_update, and the transcript retains all of them. One tool call in a real task had 9,417 updates growing to ~230KB each — 312MB of near-identical snapshots, of which only the merged final state (~3MB) is ever rendered. Connected sessions never evict, so N big transcripts stay fully resident at once.

Changes

Collapse superseded tool_call_update snapshots — merged into one update per toolCallId (shallow, later fields win, matching the renderer reducer's Object.assign) — at three layers:

• Read (renderer, on load, convertStoredEntriesToEvents) — caps retained memory.
• Transfer (workspace-server readLocalLogsCollapsed, exposed to the renderer via the host router) — collapses before IPC so a tool-heavy log doesn't cross at full size; keeps the original line count for resume/gap tracking.
• Write (agent SessionLogWriter) — buffers in-progress updates and writes one merged update per toolCallId (flushed by a terminal update, any non-tool event, a 2s max-hold, or shutdown) so new local logs are born small. The API path still receives every update uncoalesced.

Updates are merged rather than dropped because they carry disjoint fields at different times (streamed rawInput snapshots, input-derived title/diff content, then a terminal update with only status/rawOutput); keeping only the last one would strip inputs and Edit/Write diffs from ~half of all tool calls on reload. fetchSessionLogs falls back to the plain read if the collapsed procedure fails on a host (tRPC proxy clients can't be feature-detected by presence).

Live streaming display is unchanged (updates still stream via the subscription). No migration required: existing logs collapse on load. Shrinking existing logs on disk (first-load speed / disk reclaim) is an optional follow-up.

How did you test this?

Unit tests for each layer (merge-union per toolCallId, terminal-merge, order preservation, API-path entries unmutated; server-side line collapse + line-count preservation; agent coalescing flush paths incl. the hold-window split). Plus CDP measurement, a real-data replay through the built writer, and a full end-to-end run in the dev app against the real prod tasks that reproduced the balloon:

Metric	before (main)	after
Retained JS heap, 7 big tasks + forced GC	1220 MB	174 MB
Peak heap, 7 big tasks	2785 MB	307 MB
Data over IPC on load	~327 MB	~3 MB
Agent write (replay of a real 239MB / 142,893-update log)	142,893 tool updates	4,785 (4.7x smaller on disk)

The 7 tasks include the one whose 9.4k-update tool call alone added ~1.8GB on main; it now adds ~130MB.

The merge-collapse was additionally validated for correctness against the five biggest real local session logs (up to 88MB): the merged output deep-equals a full replay of every update, per tool call. The table's numbers were measured on the earlier keep-last variant; merging retains ~95% of the size reduction (e.g. 88MB log → 17MB merged vs 14MB keep-last), so they remain representative.

Honest caveats: the memory win (read + transfer collapse) is validated end-to-end in the app; the agent write-layer's born-small new logs are validated by replaying real agent output, not yet by a fresh app-spawned run. Load wall-clock for already-on-disk 327MB logs is unchanged (Node still scans the file); the memory win applies regardless.

Automatic notifications

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

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit a3bf5ab.}

[greptile-apps]

Comments Outside Diff (1)

1. packages/agent/src/session-log-writer.test.ts, line 554-594 (link)

   Time-based flush path has no test coverage

   The three new tests cover the "flushed by non-tool event," "flushed by terminal update," and "flushed by flushAll" paths, but the Date.now() - existing.bufferedAt > TOOL_UPDATE_MAX_HOLD_MS branch in appendRawLine (the 2s time-based flush) has zero coverage. That code path — write the OLD existing entry and start a fresh timer when a new update arrives after the hold window — could silently regress. Adding a test that mocks Date.now (or uses vi.useFakeTimers) and sends updates more than 2 s apart would cover it.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

_{Reviews (1): Last reviewed commit: "perf(agent): coalesce in-progress tool_c..." | Re-trigger Greptile}