fix: preserve session state on session expiration, abort, and compaction (Fixes #1054)

[Utkarsh-X]

Fixes #1054

Summary

Fixes an issue where sending a message (such as "continue") after a free session expires or after interrupting with Esc causes the assistant to lose all conversation memory and restart exploration from scratch.

Root Cause

1. Missing in-memory state update on errors / session expiration (use-send-message.ts):
   When a free session ends or fails with a gate error, the catch (error) block in use-send-message.ts calls saveChatState to persist the snapshot to disk, but does not update previousRunStateRef.current in React memory. When the user sends a follow-up prompt in the same running session, sendMessage reads the un-synced previousRunStateRef.current, causing sdk/src/run.ts to instantiate a blank initialSessionState (messageHistory = []).

2. Abort race condition (use-send-message.ts):
   When a user interrupts with Esc, the UI input lock was released before client.run() finished resolving without synchronously assigning previousRunStateRef.current = latestRunStateSnapshot.

3. Compaction continuation guidance (compact-history.ts, context-pruner.ts):
   When deterministic compaction runs, the history is collapsed into a synthetic summary. Because the system prompt retains # Initial Git Changes, models seeing 0 assistant turns occasionally re-ran exploratory git diff and tree commands.

Changes

• cli/src/hooks/use-send-message.ts:
  • Assign previousRunStateRef.current = latestRunStateSnapshot and setRunState(latestRunStateSnapshot) inside registerActiveRun upon abort.
  • Assign previousRunStateRef.current = latestRunStateSnapshot and setRunState(latestRunStateSnapshot) in the catch (error) block alongside saveChatState.
• cli/src/hooks/helpers/send-message.ts:
  • Updated the abort listener comment to reflect synchronous state preservation.
• packages/agent-runtime/src/compact-history.ts & agents/context-pruner.ts:
  • Clarified CONTINUATION_TEXT (in 100% parity) to instruct models that initial repository exploration is already recorded in <historical_memory>.

Verification

• bun test sdk/src/__tests__/run-cancellation.test.ts (16 passed)
• bun test cli/src/utils/__tests__/run-state-storage.test.ts (37 passed)
• bun test packages/agent-runtime/src/__tests__/compact-history.test.ts (31 passed)
• packages/agent-runtime/src/__tests__/context-pruner-parity.test.ts (13 passed)
• agents/__tests__/context-pruner.test.ts (69 passed)
• bun run build:sdk and bun run build:freebuff both compile with exit code 0.

Thanks for the detailed root-cause writeup — this is a well-documented PR and the instinct (sync previousRunStateRef before disk save resolves) is reasonable. A few things to strengthen before this is portable:

1. No new test covers the actual bug. You cite passing existing suites (run-cancellation.test.ts, run-state-storage.test.ts, etc.), but none of those appear to exercise the specific regression: send a follow-up message immediately after abort/expiration and assert messageHistory is preserved rather than reset to []. Without a repro test, this fix could regress silently later, and a maintainer can't confirm the root cause is actually what you describe versus a coincidental fix.

2. Duplicate state assignment logic. The same previousRunStateRef.current = latestRunStateSnapshot; setRunState(latestRunStateSnapshot) pair is now inlined in two places (registerActiveRun's abort handler and the catch block). Worth factoring into a small helper to avoid drift if one branch is updated later without the other.

3. Prompt text changes (compact-history.ts, context-pruner.ts) are the riskier part. These affect model behavior broadly, not just the abort/expire path this PR is nominally about — bundling a system-prompt tweak with a state-sync bug fix makes it harder to isolate cause/effect if either regresses. These two concerns would be easier to review (and port) as separate PRs.

4. Confirm setRunState doesn't trigger an unwanted re-render/flash given it's now called synchronously in the abort listener as well as the catch block — worth a sentence on why that's safe.

Overall the direction is right but this needs a regression test demonstrating the fixed behavior, and ideally splitting the prompt-text change into its own PR.

Thanks for the thoughtful review and constructive feedback. I've addressed all four points in the latest commit (f1418c3):

1. Regression Tests (cli/src/hooks/helpers/__tests__/send-message.test.ts)

Added a dedicated test suite verifying the exact regression path:

• User Abort (Esc): Simulates an active turn receiving user input, assistant thought, and a completed read_files tool call. Verifies that upon abort, previousRunStateRef.current is immediately populated in memory, so createRunConfig produces a runConfig.previousRun containing the full 3-item messageHistory rather than resetting to undefined/[].
• Session Expiration / Error: Tests the catch (error) branch (e.g. session ended banner) to ensure sending "continue" preserves context from the expired session.
• Cross-Chat Isolation: Tests that syncRunState is a no-op if the user switches chats mid-flight (runChatIsCurrent() === false), ensuring interrupted turns never bleed into unrelated conversations.

2. Factored Duplicate State Sync Logic (cli/src/hooks/use-send-message.ts)

Consolidated the state assignment into a single closure in sendMessage scope:

const syncRunState = (state: RunState) => {
  if (!runChatIsCurrent()) return
  previousRunStateRef.current = state
  setRunState(state)
}

Apologies — this PR was auto-closed by GitHub when we force-pushed a history rewrite of this repository (repository maintenance; every commit SHA changed). That was not a judgment on this PR, and GitHub does not allow us to reopen it because the commits it was based on no longer exist in the new history.

If you'd like to continue with this change: rebase your branch onto the new main (or recreate it from a fresh clone) and open a new PR — feel free to link back to this one for context, and we'll pick up the review there.

Sorry for the churn, and thanks for contributing.

No worries at all, totally understand the history rewrite!

I've rebased cleanly onto the new main and opened #1181 with all the review feedback and regression tests addressed. We can continue the review there!