Fetch only the collector runs the build monitor shows

[anth-volk]

Fixes #215

Summary

The build monitor shows a country's 60 most recent hosted runs (STAGING_RUN_LIMIT in frontend/lib/microcosm/build-runs.ts). Until now, loadCollectorRuns asked the telemetry collector for 200-run pages and followed every cursor, reading the country's whole run history on each list request, and loadCollector then threw away all but 60.

loadCollectorRuns(country, limit) now asks each page only for the runs still needed, capped at the collector's 200-run page maximum, and stops once it holds limit runs or the history ends. The build monitor passes STAGING_RUN_LIMIT, so a list request is now one GET /v1/runs?country=XX&limit=60.

The collector already supported this: GET /v1/runs accepts limit from 1 to 200 and a before keyset cursor, lists runs newest first by (registered_at, run_id), and sets next_before on every full page (telemetry-service/telemetry_collector/app.py, storage.py). The collector is unchanged.

Commits

1762951 Fetch only the collector runs the build monitor shows

Adds lib/microcosm/test-support/fake-telemetry-collector.ts, an in-memory collector behind a fetch stub. It follows the collector's listing rules (newest first, limits from 1 to 200 with a 422 outside them, opaque cursors, a cursor on every full page) and records each list and document request.

New tests:

• Bounded requests: requests only the most recent runs in one bounded collector request (500 runs: one limit=60 request); the build monitor reads only its 60 most recent collector runs (end to end through loadBuildRuns on the zz fixture country, which has no staging repository: one list request with limit=60, 60 document requests, the 60 newest runs).
• Same result as before: returns the same most recent runs as reading the entire history compares the result with the first 60 runs of the old read-everything path over 250 runs.
• Edge cases: fewer than 60 runs (12); exactly 60, where the collector sends a cursor and the client doesn't follow it; 61, where the oldest run is left out; short pages, where cursors are followed for only the remaining 60, 35 and 10 runs; limits above 200 (200, 200, 50); and the history ending inside a page.
• Error handling unchanged: HTTP failure status, a page without a runs array, an invalid summary, an invalid cursor, a repeated cursor, a later page failing (rejects rather than returning a partial list), and the existing Secret Manager failure test.

The existing loads every collector list page and authenticates server-side test is renamed authenticates every collector list request server-side and passes the limit. Its assertions are unchanged.

• Red (new tests against the unchanged code): 8 failed, for the intended reason: list request count, the requested limit (200 instead of 60), or a result longer than 60 runs. 17 passed: the 10 existing tests, plus 7 that were expected to pass on both versions (the error-handling tests and the end-of-history boundary).
• Green: 25 passed, 0 failed (telemetry-collector-client.test.ts, build-runs.test.ts).
• Gates:
  • bun test, full frontend suite: 618 passed, 0 failed, across 77 files;
  • bun run lint (tsc --noEmit): clean;
  • bun run build (next build): succeeded;
  • bun run test:dev-port: 4 passed.

Findings

• Where 60 comes from: STAGING_RUN_LIMIT = 60 in build-runs.ts. It bounds both the collector list and the Hugging Face staging history list. The collector's own default limit is also 60.
• The first 60 runs are unchanged: the collector's listing is a stable keyset order, so a single limit=60 page holds exactly the first 60 runs of the full history.
• Caching is unchanged: the 30-second list cache and the per-run document cache work as before. The client already skipped refetching finished, unchanged runs, so the saving is in list requests, which used to be ceil(history / 200) per country every 30 seconds and are now one.

Risks

• Listing contract: this relies on the GET /v1/runs contract as it stands on main (limit up to 200, newest-first keyset cursors). A later read API change (the collector's v2 read API) must keep that order and the limit parameter, or update this client with it.
• A collector that serves short pages: cursors are still followed, asking only for the remaining runs, and that case is tested.
• Unbounded empty pages (pre-existing, not reachable today): a collector that returned empty pages with new cursors forever would still loop, as before. The real collector sends a cursor only on full pages.

Deploy implications

• Merging deploys to production: deploy.yml runs on CI's workflow_run completion for pushes to main. It deploys the Modal backend, then builds, verifies and promotes the Vercel frontend.
• Environment: no environment variables, secrets or workflows change. The client still reads only MICROCOSM_TELEMETRY_COLLECTOR_URL and MICROCOSM_TELEMETRY_READ_SECRET_VERSION.
• Collector: no change or redeploy is needed.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
calibration-diagnostics	Ready	Preview	Oct 15, 2026 7:37pm UTC