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

The cloud settings page's Server-Timing names its phases: session, each read, render #3472

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

`GET /settings/cloud` now answers with a Server-Timing header naming `session`, `reads`, `uses`, `accounts` and `render`, the same way the milestones page does.

shipped production is serving it deploy 119f4d2

opened this

GET /settings/cloud now answers with a Server-Timing header naming session, reads, uses, accounts and render, the same way the milestones page does.

I could not run the type check. bun x tsc --noEmit and bun install both failed in this sandbox with "bun is unable to write files to tempdir", so the forge's check will be the first type check. The new test and the existing test/cloud.test.ts and test/cloud-gate.test.ts pass (21 tests).

  • Change: the phases come from notePhase and timePhase in src/core/route_timing.ts, in src/web/pages/cloud.ts.

- session is recorded first, before the admin check. - reads wraps recentCloudReads. - uses wraps usesByVendor, with the async variant of timePhase. - accounts wraps listCloudAccounts. - render times building the page.

  • Account list moved: listCloudAccounts used to be called inside accountsCard. It is now called in cloudPage, after usesByVendor and before the page is built, so it runs in the same order as before. accountsCard takes the list as an argument.
  • Unchanged: the page's body, status codes and caching.
  • Test: test/cloud-timing.test.ts requests the page as an admin. It asserts each of the five names appears exactly once with a numeric duration, and no wall-clock time. It fails without the change because the header lacks those names.
  • Left out: the POST handlers and /settings/cloud/audit are not timed.

To try it, sign in as an admin, open /settings/cloud, and read the Server-Timing response header.

🤖 Generated with Claude Code

Closes #3444

commented

GET /settings/cloud now answers with a Server-Timing header naming session, reads, uses, accounts and render, the same way the milestones page does.

I could not run the type check. bun x tsc --noEmit and bun install both failed in this sandbox with "bun is unable to write files to tempdir", so the forge's check will be the first type check. The new test and the existing test/cloud.test.ts and test/cloud-gate.test.ts pass (21 tests).

  • Change: the phases come from notePhase and timePhase in src/core/route_timing.ts, in src/web/pages/cloud.ts.

- session is recorded first, before the admin check. - reads wraps recentCloudReads. - uses wraps usesByVendor, with the async variant of timePhase. - accounts wraps listCloudAccounts. - render times building the page.

  • Account list moved: listCloudAccounts used to be called inside accountsCard. It is now called in cloudPage, after usesByVendor and before the page is built, so it runs in the same order as before. accountsCard takes the list as an argument.
  • Unchanged: the page's body, status codes and caching.
  • Test: test/cloud-timing.test.ts requests the page as an admin. It asserts each of the five names appears exactly once with a numeric duration, and no wall-clock time. It fails without the change because the header lacks those names.
  • Left out: the POST handlers and /settings/cloud/audit are not timed.

To try it, sign in as an admin, open /settings/cloud, and read the Server-Timing response header.

🤖 Generated with Claude Code

Approved

Follows the pattern boards-view, forges and settings already use (notePhase/takeSessionTime/timePhase), no markup or design change, admin gate unchanged, and the test pins all five phase names once each with numeric durations. I could not reach the preview from my sandbox, so this is a source read only. Next: (1) time the POST handlers and /settings/cloud/audit the same way; (2) the test titles say #3444 while the pull is #3472, so align the reference.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs