todo: refresh loses a finished turn's output — replay shows an empty fold

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-25 06:12:42 +00:00
parent 70acccfe0c
commit ee1cd006af
2 changed files with 40 additions and 3 deletions
@@ -0,0 +1,37 @@
+---
+id: known-bugs/refreshing-a-finished-chat-turn-loses-output
+title: 'Refreshing a finished chat turn loses output — replay collapses to a fold and the closing message vanishes'
+theme: known-bugs
+status: open
+created: 2026-08-25
+date_source: stated
+order: 4
+---
+
+**Refreshing a finished chat turn loses output.** Reported by the owner 2026-08-25, with a screenshot:
+a Command HQ chat (the "Voice Memos" commander, first turn), refreshed after the turn completed, shows
+the prompt, then one collapsed seam reading `6 tool calls · 3 messages · 3 failed`, then
+`TURN FINISHED · NO CLOSING MESSAGE`. The turn's actual output — including AskUserQuestion activity the
+prompt explicitly requested — is gone from view. The header confirms how wrong the fold is:
+`0 turns · 0 tok · $0` on a session that plainly ran six tool calls. He reports this happens "a lot of
+times" on refresh, not once.
+
+Two distinct wrongs, and they may have different owners:
+
+1. **The collapse itself is (he recalls) a deliberate decision** — fold past tool calls on replay. If
+   so, the decision needs revisiting where it hides MESSAGES, not just tool chatter: "3 messages" inside
+   a collapsed seam means prose the agent wrote is behind a click, and a first-time reader concludes the
+   turn produced nothing.
+2. **"No closing message" on a turn that had one.** The fold's own code says that banner was built for
+   turns that genuinely ended without an answer, and its comments record it once mis-fired for streams
+   (`turn-rows.ts:178`, `types.ts:38` — "printed 'Turn finished · no closing message' under work that
+   was still going"). A replay reaching that state on a turn that DID close means the replay source is
+   missing the final message — so look at what the fold is FED on refresh, not at the fold: the event
+   log the page replays (`chat_session_events` → `turn-rows.ts` folding) versus what the live socket
+   streamed. `3 failed` inside the seam is a second clue about what the stored events actually hold.
+
+Where to look, verified in the tree: `Chat/components/turn-rows.ts` (the folding, with its own history
+of exactly this class of bug in comments and tests), `TurnFold.tsx:88` (renders the banner), and
+whatever writes the durable events the replay reads — the claude sidecar has owned `chat_session_events`
+writes since the isolation work. Note `0 turns · 0 tok · $0` suggests the commander's turn ledger also
+saw none of it, which points the same direction: the durable record, not the renderer.