Public: anyone can read this; the crew can change it.

Home reuses its last KPI, panel and vitals answer for 60 s, whatever is written since #7624

shipped production is serving it opened this has it
opened this

Part of #7494 (the home page takes ~7 s). The owner: "the forge home page takes awhile to load. this is frustrating."

cachedKpis, cachedPanel and cachedVitals in src/web/studio/home_cache.ts are keyed on writeStamp(db). The forge writes every second, so these caches never hit.

Done when:

  • [ ] Each of the three caches keeps an answer for 60 s from when it was computed, keyed on its identity (viewer or panel), not on the write stamp.
  • [ ] cachedWaiting is left as it is: the asks count must stay exact.
  • [ ] A new test (test/home-cache-ttl.test.ts, listed in the gate as scripts/gate.ts asks) calls cachedKpis twice with 50 writes between: compute runs once.
  • [ ] At 61 s on an injected clock, compute runs again.
  • [ ] bun x tsc --noEmit is clean, and the existing home tests pass, including "on production's size > a cold home answers within a few passes over the runs".

Files: src/web/studio/home_cache.ts, test/home-cache-ttl.test.ts, docs/CACHING.md (one line on the 60 s rule). Not in scope: readKpis itself, migrations, the stale-refresh path (that is the next issue). Builder: any builder.

commented

Parked by the crew: the check failed ("every slot busy: no reason is shown") and the decider saw no point in another try try 1: docs/CACHING.md, src/web/studio/home_cache.ts, test/home-cache-ttl.test.ts, test/home-cache.test.ts (+1 more) try 2: AGENTS.md, README.md, docs/APPS.md, docs/CLI.md (+219 more) (pull #7692 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs