3a45f02b · zzmq.dev@gmail.com/zz
Commit
3a45f02bf72ceec48b3761bccccbeb79078192d6
Add readLadderTree: one cached call for the whole tree, not one per rung Direct instruction: "cache at every level and invalidate cache only on ladder updates so that it can be warmed." Implements that as a new Backend.readLadderTree(repo) method, replacing the pattern every caller (the TUI, the web app's own Ladder tab) used to drive themselves: walk the tree with one readAnchor/ladder_read call per rung. That pattern is why remote Ladder reads were so much slower than local ones -- a local read is a git-notes lookup against a repo already on disk (microseconds); a remote read is "git fetch one notes ref over HTTP, from scratch, per distinct ref" (hundreds of ms each), and the CLI/TUI paid a FULL public-internet round trip on top of that for every single rung. Collapsing N round trips into 1 fixes both costs: one call regardless of tree size, matching the concern that this would only get worse on a repo with many files/changesets. - engine/backend.ts: new interface method, doc comment explains why each backend needs its own strategy. - engine/localBackend.ts: trivial -- no network cost to begin with, delegates straight to collectLadder. - cli/lib/remoteBackend.ts: routes through the new ladder_tree tool. - worker/src/cloudflareBackend.ts: the real fix -- a durable-storage- backed cache (survives DO eviction, unlike the in-memory notesCache from earlier this session), checked first on every read, populated on a miss, invalidated unconditionally on every writeLadder/ appendRepoChildren call (can't cheaply tell in general whether a given write touched what a cached tree already reflects, so don't try -- just invalidate, next read recomputes once and re-caches). - agent/tools.ts: new ladder_tree tool, dispatched through the same generic server-side tool-calling path every other tool uses. - tui/useLadderTrees.ts / worker/src/webApp.ts: both now call this once instead of manually walking ladder_read/stub.callTool per rung -- webApp.ts's old 300-node-cap manual resolve() is gone entirely, replaced by one stub.callTool("ladder_tree", ...). Verified live against the real deployed Worker: a cache hit (one durable-storage read, no Artifacts/git calls at all) measured 3-5x faster than a cache miss on repeat calls to the same repo. Also surfaced two things NOT fixed here, worth flagging separately: (1) a repo's MaintainerDO can keep running pre-deploy code for a while after a real deploy (confirmed again live, same as earlier sessions) -- not something client-side code can work around; (2) doCreateRepo's initial Ladder bootstrap (buildInitialLadderRungs -> ladder_write_rung) appears not to reliably leave a real "_repo" rung behind on a brand-new repo (ladder_read "_repo" returned null on two separate fresh test repos) -- a real, separate bug, pre-existing and unrelated to this change, not investigated further here.
Troy Howard <thoward37@gmail.com> -- 2026-10-13T07:41:24.000Z