Skip to content

feat(terminal): keep recent sessions warm - #195

Closed
Lint111 wants to merge 2 commits into
Ark0N:masterfrom
Lint111:agent/split-warm-terminal-cache
Closed

feat(terminal): keep recent sessions warm#195
Lint111 wants to merge 2 commits into
Ark0N:masterfrom
Lint111:agent/split-warm-terminal-cache

Conversation

@Lint111

Copy link
Copy Markdown
Contributor

Summary

  • keep the active terminal and two recently viewed sessions in a bounded 30-second live range
  • restore eligible revisits from the in-memory xterm snapshot plus an ordered, capped live delta
  • skip the canonical terminal fetch only when stream coverage and the rendered snapshot were both confirmed before demotion
  • invalidate replay on clear, backpressure, transport recovery, overflow, expiry, deletion, and forced reload
  • serialize subscription updates and use the same per-tab transport identity as the terminal WebSocket

Why

Every session switch currently downloads and replays the terminal tail. On mobile, rapid switches can expose stale frames, repeat expensive xterm parsing, and make recently viewed sessions feel cold even though their rendered state is already in memory.

This change keeps a small recent range live. A quick switch-back becomes:

  1. restore the prior rendered snapshot;
  2. apply terminal bytes received while the session was inactive; and
  3. flush live bytes queued during the switch transaction.

Any uncertainty falls back to the existing canonical fetch.

Correctness Boundaries

  • A retained entry is not automatically replayable.
  • Replay eligibility is frozen when a canonical, subscription-confirmed active session is demoted.
  • A late subscription acknowledgement cannot retroactively validate a potentially gapped snapshot.
  • Clear and recovery events increment a replay generation, so an in-flight restore cannot commit stale state.
  • Async recovery handlers recheck active-session ownership after network and chunked-write awaits.
  • Shell sessions are removed when demoted because they do not use xterm snapshot restoration.
  • The cache is capped at three sessions and 256K JavaScript characters of delta per entry.

Dependencies

Merge order:

  1. feat(terminal): add bounded snapshot and history streaming #189 adds the backend per-tab transport ID, explicit empty subscription, bounded snapshot/history, and transport handoff contracts.
  2. fix(terminal): preserve replay and history ownership #193 adds caller-owned terminal replay transactions.
  3. This PR adds the bounded recent-session client cache.

This branch temporarily includes 92dbe64 from #193 and should be rebased after #193 merges. It does not duplicate #189. Before #189 is present, the extended subscription ID is rejected and entries remain ineligible, so the client safely uses canonical loads.

Commit Structure

Out Of Scope

Validation

  • npx vitest run --config config/vitest.config.ts test/warm-terminal-cache.test.ts test/terminal-flush-budget.test.ts test/codex-snapshot-replay.test.ts test/terminal-buffer-flush.test.ts - 26 passed
  • npm run check:lockfile
  • npm run typecheck
  • npm run lint
  • npm run check:frontend-syntax
  • npm run check:public-assets
  • npm run format:check
  • npm run build
  • git diff --check

The unsafe bare full-suite path was not run; its destructive quick-start fixture is isolated separately in #175.

@Ark0N

Ark0N commented Aug 5, 2026

Copy link
Copy Markdown
Owner

Hi Lior, closing this one as part of a cleanup of the seventeen PRs currently open from you. The full explanation is in #173, and I would rather you read that one than this note, because it is the honest version and it is not a dismissal of your work.

The short form: sixteen PRs opened in a single day, roughly 42,000 added lines in total, landing mostly on the same few files (nine touch app.js, eight touch terminal-ui.js), with five already conflicting against master and none carrying CI results. I cannot review that at the standard this codebase needs, and merging it at a lower standard would be worse than not merging it.

Going forward, please keep no more than three open PRs at a time, each one a single behavior change that stands on its own, with a test that fails on master and passes with the fix. #214 and #215, merged today, are good models.

If this particular change fixes something that genuinely annoys you in daily use, it is a good candidate to be the first one you reopen on its own, rebased on current master. I will review it properly.

Thanks for the effort you put in, and sorry to close it this way.

@Ark0NArk0N closed this Aug 5, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@Lint111@Ark0N