Skip to content

Cache conversation sidebar metadata by head commit - #170

Open
nishu-builder wants to merge 1 commit into
claude/tui-startup-latency-upbs92-p1from
claude/tui-startup-latency-upbs92
Open

Cache conversation sidebar metadata by head commit#170
nishu-builder wants to merge 1 commit into
claude/tui-startup-latency-upbs92-p1from
claude/tui-startup-latency-upbs92

Conversation

@nishu-builder

Copy link
Copy Markdown
Contributor

Stack 2/2, on top of #169 — merge that first, then retarget this to main (or let GitHub retarget it automatically when #169's branch is deleted on merge). The diff shown against the stack base is exactly this PR's one commit.

Problem

Every sidebar listing walked every conversation's event history from its head all the way to the root — remote_conversation_metadata needs the newest user activity and the durable parent, and both live at the far end of the chain. That is O(events) commit reads per conversation per listing, each one a server round trip when the commit is not yet local; the tui pays it at startup for the whole sidebar and again on every 500ms remote poll, and a fresh process (the tui launches one per run) started from nothing.

Change

The answer for a head is pure content: a commit fixes its first-parent chain, so its metadata can never go stale. Cache it per head:

  • A process-wide memo plus one sidecar file per git dir (.git/caos-conversation-metadata), loaded once per process and appended as heads are summarized; compacted to the newest 2048 entries when it grows past 8192 lines. Torn or hand-edited lines are skipped, never an error — a cache read must only ever cost the rewalk it failed to save.
  • A walk now stops at any previously summarized head and combines: the newest user activity is whichever comes first from the tip, and the parent lives on the root either way. Listings read only the events that landed since the last one — across process restarts too — and a fork stops at its source conversation's summarized spine the same way.
  • GitTransport gains a git_dir() accessor for the sidecar path (per-checkout: linked worktrees keep their own, a deleted checkout takes its cache with it).

Validation

  • Full caos (32), caos-cli lib (51) and tui bin (138) suites green, including four new tests: cache-line round-trip + junk skipping; an advanced head that provably reuses the cached boundary (the old commit's loose object is deleted first, so a rewalk would fail loudly); sidecar entries serving a fresh repo with no objects at all; compaction of an oversized sidecar.
  • cargo check --workspace, cargo fmt --check clean; clippy shows only a pre-existing warning in untouched code.
  • Not run here (no nix / no stack in this environment): nix build and the salted run-tool test gate.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AZgAh1BJk17ge3SasEaCJJ


Generated by Claude Code

Every sidebar listing walked every conversation's event history from its
head all the way to the root — remote_conversation_metadata needs the
newest user activity and the durable parent, and both lived at the far
end of the chain. That is O(events) commit reads per conversation per
listing, each one a server round trip when the commit is not yet local;
the tui pays it at startup for the whole sidebar and again on every
500ms remote poll, and a fresh process (the tui launches one per run)
started from nothing.

The answer for a head is pure content: a commit fixes its first-parent
chain, so its metadata can never go stale. Cache it per head — a
process-wide memo plus one sidecar file per git dir, loaded once and
appended as heads are summarized (compacted to the newest entries when
it grows past a bound). A walk now stops at any previously summarized
head and combines: the newest user activity is whichever comes first
from the tip, and the parent lives on the root either way, so a listing
reads only the events that landed since the last one — across process
restarts too — and a fork stops at its source conversation's summarized
spine the same way.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AZgAh1BJk17ge3SasEaCJJ
Sign up for free to 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