bug(agent-loop): prompts are lost when a turn is aborted during auto-compaction; compaction also has no UI state

[omnisurge]

Summary

Two related findings from a real session that crossed the auto-compaction threshold:

1. Data loss (bug): when a turn is aborted while pre-step auto-compaction is running, the user prompt that triggered the turn is permanently lost — it never reaches the session log and is not returned to the visible queue.
2. UX gap: compaction has no distinct activity state. The chat shows the generic Deep diving… turn label for every phase, so a slow/hung summarization request is indistinguishable from model thinking — which invites exactly the abort that triggers the data loss above.

Environment

• dsh 0.1.0-rc.6, dsh web GUI, preset code
• Routed provider: Anthropic-compatible endpoint, model k3, configured contextWindow: 500000
• Session: 68 completed turns, ~400K prompt tokens (inputTokens 1861 + cacheReadTokens 398080 on the last healthy step) — just over the compaction threshold, so every new turn began with mandatory pre-step compaction

Timeline (from the session event log)

turn	events	outcome
68	last healthy step	turn/end completed
69	prompt → turn/start → compaction/start (+53ms)	no output for 101s → user aborts → compaction/end error="This operation was aborted", turn/end aborted{user}
70	prompt → compaction/start	79s no output → user aborts, same end state
71	prompt → compaction/start	aborted again after 2.5s
72	(next day, endpoint healthy) prompt → compaction/start	compaction/end OK in 68s → step runs → turn/end completed

None of the prompts for turns 69–71 exists anywhere in the 19,337-line session log — no user/message events were ever recorded for them. Turn 72 proves the session was never corrupt: it was simply blocked on compaction every time.

Mechanism (source citations, 0.1.0-rc.6)

• Message loss. packages/core/agent-loop/src/agent.ts: the turn loop claims inbox messages in preStep (:229) and only appends user/message once the first step actually runs (:283). Compaction runs earlier, inside the agent/pre-step waterfall (:266 → :234). Aborting in that window kills the turn after the messages were claimed but before they were persisted — they vanish from both the log and the UI queue.
• No compaction UI state. packages/client/ui-conversation/src/client/chat/ChatView.tsx:132 renders a single turn-level label Deep diving… for all phases ("retained across first-token, tool, and streaming phases"). compaction/start / compaction/end events exist in the session event stream, but the client does not surface them.
• Silent hang. The summarization call replays the whole shadowed region (compaction-basic/src/summarizer.ts), i.e. a ~400K-token request here. It produced no partial output and no llm/retry events in the session log before the aborts — from the user's seat the session simply looked dead.

Why this matters

• Losing a composed prompt is unrecoverable user data loss, and it only takes a slow provider at the wrong moment — large sessions are the norm for long agent runs.
• The UX actively invites the triggering action: a generic spinner with no explanation, for 80–100+ seconds, right after the user hit send.

Suggestions (non-prescriptive)

1. Persist claimed messages before the pre-step waterfall (or at claim time), or return them to the inbox when the turn aborts before user/message lands — a cancelled turn should not eat the prompt.
2. Surface compaction as a distinct activity state (e.g. Compacting context…) keyed off the existing compaction/start|end events.
3. Consider a visible timeout/retry story for the summarization call; today a hung compaction is silent in both the UI and the session event stream.

Happy to share the raw session log excerpt privately if useful.

Notes

• Verified the session recovers fully once compaction completes (turn 72 above), so this is not a persistence-corruption issue — it is specifically the abort-during-compaction window.