Agentic UI: Stop the About card's disk measurement from thrashing on site switches

[shaunandrews]

Related issues

• Fixes STU-2305

How AI was used in this PR

Claude investigated the report, measured the costs below, and wrote the fix and tests. Numbers in "Proposed Changes" are measured on a real machine (15 sites, 3,700–12,400 files each), not estimates.

Proposed Changes

Switching between a few sites quickly made the whole app crawl. The About card's Disk row measured the site's folder from scratch on every switch, moving on didn't stop the measurement already running, and nothing waited to see whether the user actually meant to land on that site — so flicking through eight sites in ten seconds left eight full measurements in flight at once.

Three things caused it, all fixed here:

• The browser UI forked a whole CLI process per request. GET /sites/:id/storage (and /wp-version, which the same card requests) called listSites purely to map a site id to its path. That fork measured 1.9s wall and 1.2s CPU; six concurrent ones took 2.5s wall and ~7s CPU. Both routes now read the path straight out of cli.json — 0.1ms, verified against all 15 real sites on disk. Routes that need live fields or must observe a write the CLI just made still go through listSites.
• Measuring started the instant a site appeared. The site workspace remounts per site, so every site passed through on the way to the intended one paid for a full directory walk. A measurement now waits until the site has been on screen for 400ms. A site revisited within the cache window still shows its number instantly.
• Abandoned measurements ran to completion. The query discarded React Query's AbortSignal, so leaving a site left its walk running — on Desktop, inside the main process. The signal is now honored end to end: the walk itself checks it, the browser ties it to the HTTP request, and Desktop cancels through a companion IPC call since ipcRenderer.invoke has no cancellation of its own.

No visual change — the Disk row looks and reads exactly as before.

Two related things this deliberately leaves alone, noted in STU-2305 for follow-up: the measurement still isn't cached or deduped server-side, and the thumbnail/wp-version queries still inherit staleTime: 0 so they refetch on every mount and window focus.

Testing Instructions

Browser UI (npm run cli:build:ui && node apps/cli/dist/cli/main.mjs ui --no-open, then http://localhost:8081):

1. Open a site's Overview and confirm the Disk row still measures and renders its breakdown.
2. Click quickly through six or more sites in the sidebar. Previously this spiked CPU hard (a CLI process per switch); it should now stay flat, and no measurement should fire for a site you only passed through.
3. Land on a site, then leave within a second. The abandoned request should stop rather than finish.
4. Request /api/sites/does-not-exist/storage and confirm it still 404s.

Desktop: same walkthrough in the app. Rapid site switching should no longer bog down the UI.

Unit tests: npm test -- apps/cli/tests/local-server.test.ts packages/common/sites apps/ui/src/data/queries/use-site-storage-usage.test.tsx

Full suite run before/after: identical failure sets (39 pre-existing failures in this worktree, all from missing optional deps — @wp-playground/blueprints, wpcom/types, @types/archiver), zero introduced.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing 16be217 vs trunk

app-size

Metric	trunk	16be217	Diff	Change
App Size (Mac)	1436.08 MB	1436.09 MB	+0.01 MB	⚪ 0.0%

site-editor

Metric	trunk	16be217	Diff	Change
load	1192 ms	1195 ms	+3 ms	⚪ 0.0%

site-startup

Metric	trunk	16be217	Diff	Change
siteCreation	7513 ms	7507 ms	6 ms	⚪ 0.0%
siteStartup	2883 ms	3383 ms	+500 ms	🔴 17.3%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)