04e8cecf · zzmq.dev@gmail.com/zz
Commit
04e8cecfd0097e5b2aab6207e5c22c2bdf21f0ce
Fix zz top's Ladder tab: configure() was discarding its own cache on every call Root-caused "not seeing ladder" in zz top: resolveLadderTree makes one HTTP request per rung (6 for shoes: 1 root + 5 children), and handleApiCallTool calls stub.configure() on every single one of those requests. configure() unconditionally rebuilt the whole Backend object (and so cloudflareBackend.ts's notesCache, added earlier this session specifically to stop redundant git-notes checkouts) -- so that cache never actually survived from one HTTP request to the next, only within a single Worker-side function making several in-process callTool calls (webApp.ts's own getLadderTree). Every single CLI/TUI multi-call sequence defeated it completely. configure() is now a no-op when the DO is already configured for the same repo, so the Backend (and its caches) actually persists across calls for as long as the DO instance stays warm. Confirmed live via a standalone repro script hitting the real deployed Worker. Also added an in-flight guard to useLadderTrees' poll loop: a multi-second remote resolution with no guard meant a new read() could start before the previous one finished, piling up more overlapping requests the slower a repo's resolution got, which reads as "never shows anything" rather than "takes a few seconds." Remaining known cost (not fixed here, flagging for a decision): each of the 6 calls still pays its own fresh artifacts.get() + repo.createToken() -- cloudflareBackend.ts's readAnchorFor disposes that handle after every single read (the same `using`-per-call convention every other read path in this codebase follows), so caching it across calls needs care around that disposal contract, not a quick change.
Troy Howard <thoward37@gmail.com> -- 2026-10-13T07:20:34.000Z