mirror of
https://github.com/stablyai/orca.git
synced 2026-10-22 00:03:47 +00:00
Neil
d021bb4699
The main-process worktree resolution cache expires on wall-clock time: the whole-fleet snapshot has a 1s TTL, so any poller faster than 1Hz recomputes it, and every 30s the per-repo scan cache expires and shells out `git worktree list` for every registered repo. A production trace recorded 4,272 `git worktree` invocations over 3h27m across 10 repos -- one full sweep per 30.5s, independent of which caller happened to arrive first. In-Orca mutations (create, remove, rename, sparse edits, repo add/update/remove, SSH reconnect) are already event-driven, so the 30s TTL exists only to discover changes made outside Orca. That is a filesystem question, and the filesystem can answer it without a subprocess. Before re-running an expired scan for a local, non-WSL repo, read a cheap Git-admin fingerprint (admin dir entries, per-checkout HEAD and its ref tip, gitdir/locked/existence per entry, packed-refs and reftable stamps). If it matches the fingerprint captured at the cached scan's start, extend the cache without spawning Git; otherwise scan as before. A real scan still runs every 5 minutes so anything the probe cannot see -- sparse-checkout edits, a packed tip moved within one mtime tick -- still reconciles. Measured on the reported workload (10 idle repos, 1Hz polling, 30 simulated minutes): 600 -> 60 `git worktree list` spawns, a 90% reduction, with external worktree add/remove/move/lock/checkout/commit discovery still bounded at 30s. SSH repos, WSL-routed repos, folder workspaces, and any repo whose layout the probe cannot read keep today's behaviour exactly. Design: docs/reference/worktree-scan-fingerprint.md