Follow-up to #230 / #238.
#238 fixed the zoom/unzoom/list-toggle freeze for the replay_cached path (shell / codex / claude) by re-feeding only the scrollback tail on a width change instead of the whole history. The replay_full path — used by zarvis sessions that carry tool blocks — has the same root cause and was left unbounded.
Problem
On a width change, replay_full rebuilds the parser and re-runs cache.parser.process(...) over all items from index 0 (start_processing_at = 0 when needs_rebuild). For a long zarvis session this re-parses the entire history synchronously on the UI thread → the same freeze #230 described, just for tool-block sessions.
(zarvis history lives in the items list — PtyChunks + ToolBlocks flushed on OSC markers — not in one pending_chunk, which is why the replay_cached byte-offset bound doesn't directly apply.)
Why it wasn't fixed in #238
replay_full computes an item_layouts entry (visible-line count + tool-block hit-rect geometry) for every item to position blocks and compute total scroll height. Those layouts need all items, so you can't naively skip old ones without breaking scroll offsets and tool-block click targets.
The safe fix is asymmetric: keep computing item_layouts for all items (cheap, already incremental since #127), but only parser.process() the tail that survives the SCROLLBACK_MAX ring — and make the bounded parser feed line up with the layout offsets the renderer uses.
Proposed work
- On
replay_full rebuild, set start_processing_at to a scrollback-tail cutoff over items (analogous to reflow_tail_offset, but item-indexed and accounting for ToolBlock/Message synth line counts) instead of 0.
- Keep
item_layouts computed for all items so positioning/hit-rects stay correct.
- Regression test mirroring
resize_long_history_renders_correct_tail but for a tool-block session: long zarvis-style history, width change, assert the newest content + a tail tool block render correctly and the rebuild is bounded.
Priority
Lower than #238: zarvis sessions are chat-shaped (turns + tool calls), typically far less volume than a seq/build-log flood that hits codex/shell, so the freeze is much less likely to bite. Real gap, lower probability.
References
Follow-up to #230 / #238.
#238 fixed the zoom/unzoom/list-toggle freeze for the
replay_cachedpath (shell / codex / claude) by re-feeding only the scrollback tail on a width change instead of the whole history. Thereplay_fullpath — used by zarvis sessions that carry tool blocks — has the same root cause and was left unbounded.Problem
On a width change,
replay_fullrebuilds the parser and re-runscache.parser.process(...)over all items from index 0 (start_processing_at = 0whenneeds_rebuild). For a long zarvis session this re-parses the entire history synchronously on the UI thread → the same freeze #230 described, just for tool-block sessions.(zarvis history lives in the
itemslist —PtyChunks +ToolBlocks flushed on OSC markers — not in onepending_chunk, which is why thereplay_cachedbyte-offset bound doesn't directly apply.)Why it wasn't fixed in #238
replay_fullcomputes anitem_layoutsentry (visible-line count + tool-block hit-rect geometry) for every item to position blocks and compute total scroll height. Those layouts need all items, so you can't naively skip old ones without breaking scroll offsets and tool-block click targets.The safe fix is asymmetric: keep computing
item_layoutsfor all items (cheap, already incremental since #127), but onlyparser.process()the tail that survives theSCROLLBACK_MAXring — and make the bounded parser feed line up with the layout offsets the renderer uses.Proposed work
replay_fullrebuild, setstart_processing_atto a scrollback-tail cutoff overitems(analogous toreflow_tail_offset, but item-indexed and accounting forToolBlock/Messagesynth line counts) instead of0.item_layoutscomputed for all items so positioning/hit-rects stay correct.resize_long_history_renders_correct_tailbut for a tool-block session: long zarvis-style history, width change, assert the newest content + a tail tool block render correctly and the rebuild is bounded.Priority
Lower than #238: zarvis sessions are chat-shaped (turns + tool calls), typically far less volume than a
seq/build-log flood that hits codex/shell, so the freeze is much less likely to bite. Real gap, lower probability.References
reflow_tail_offset,replay_cachedincrates/cli/src/pty_render.rs)