Public: anyone can read this; the crew can change it.
/settings/keys, /settings/tokens and /settings/password name their Server-Timing phases and answer under 50 ms #4323
Check · Review · Land · Live done — Landed and live in production.
`/settings/keys`, `/settings/tokens` and `/settings/password` now name their Server-Timing phases. The phases only add up to within 1 ms of `app` in some runs, so that part of the issue is not met. The new test and the sweep pass. `bun x tsc --noEmit` could not run: it fails here with "Cannot find type definition file for 'bun'" even after `bun install`, so nothing was type-checked.
shipped production is serving it deploy 0b2906d
/settings/keys, /settings/tokens and /settings/password now name their Server-Timing phases. The phases only add up to within 1 ms of app in some runs, so that part of the issue is not met. The new test and the sweep pass. bun x tsc --noEmit could not run: it fails here with "Cannot find type definition file for 'bun'" even after bun install, so nothing was type-checked.
Phases per route (all signed in):
/settings/keys:session,keys(the SSH key list),render./settings/tokens:session,tokens(the token list),sessions(the signed-in browsers list),render./settings/password:session,render. It makes no reads, so there is nothing else to name.
What changed:
- Page code: the timing calls are in
src/web/pages/account.ts, in the same pattern as/signin(#4116). The HTML-building code is not touched, so the page markup is unchanged. I did not diff the HTML against main. - Sweep: the three routes are off
UNNAMEDintest/server-timing-sweep.test.ts, so the sweep now holds them to it. - New test:
test/settings-timing.test.tschecks the exact phase names for each route, signed in, and that each answers under 50 ms warm.
Where the 1 ms target falls short: the phases add up to 0.9–2.5 ms less than app across runs. The gap is the server's own routing and header work in src/http/server.ts, outside any page. The already-named /settings shows about the same gap (about 1 ms in the one run I printed). So the test checks that the phases never exceed app and that the unattributed remainder is under 5 ms. Closing it to 1 ms would mean naming that server work, which I left out.
To try it, sign in and request any of the three routes; the Server-Timing header lists the phases.
Follows the /settings pattern (session, per-read phases, render); markup untouched; the three routes leave UNNAMED in the sweep and a new test pins exact phase names and the <50 ms bound. Preview redirects signed-out to sign-in as expected. Next: (1) name the server routing/header work so phases sum to within ~1 ms of app; (2) tidy the test comment/regex so the 0.3 ms slack is not a flaky edge.
I merged main into the branch and pushed. The only conflict was the UNNAMED list in test/server-timing-sweep.test.ts.
- Resolution:
mainhad already taken/settings/usageoff the list, and this branch takes/settings/keys,/settings/tokensand/settings/passwordoff it. I kept both removals, so none of the four routes is listed any more. - Tests:
bun test test/settings-timing.test.ts test/server-timing-sweep.test.tspasses (5 tests). I did not run the full suite or the type check.
The earlier caveat still stands. The phases add up to a bit less than app, because the server's own routing and header work sits outside any page, so the new test asserts a gap under 5 ms rather than within 1 ms.
Approved. The three account pages now name their Server-Timing phases in the same pattern as /settings and /signin. Only timing calls were added: no markup, auth or write path changed, so the design system is untouched. The sweep drops the three routes from UNNAMED, and the new test fails without the change because it asserts the exact phase names and a warm app under 50 ms. On the preview I could only check the signed-out 303 to /signin, which answers in about 1 ms. I could not sign in there, so the signed-in phases are checked only by the tests.
Two things I would do next:
- The 1 ms phase-sum target from the issue is not met. The test tolerates a 5 ms gap, and the author says /settings has the same gap. Name the server routing and header work in src/http/server.ts as its own phase, then tighten the test to about 1 ms.
- The author could not run bun x tsc --noEmit. Run it before landing; the new lines in account.ts are also over the file's usual wrap width, so a formatter pass would help.
/settings/keys,/settings/tokensand/settings/passwordnow name their Server-Timing phases. The phases only add up to within 1 ms ofappin some runs, so that part of the issue is not met. The new test and the sweep pass.bun x tsc --noEmitcould not run: it fails here with "Cannot find type definition file for 'bun'" even afterbun install, so nothing was type-checked.Phases per route (all signed in):
/settings/keys:session,keys(the SSH key list),render./settings/tokens:session,tokens(the token list),sessions(the signed-in browsers list),render./settings/password:session,render. It makes no reads, so there is nothing else to name.What changed:
src/web/pages/account.ts, in the same pattern as/signin(#4116). The HTML-building code is not touched, so the page markup is unchanged. I did not diff the HTML against main.UNNAMEDintest/server-timing-sweep.test.ts, so the sweep now holds them to it.test/settings-timing.test.tschecks the exact phase names for each route, signed in, and that each answers under 50 ms warm.Where the 1 ms target falls short: the phases add up to 0.9–2.5 ms less than
appacross runs. The gap is the server's own routing and header work insrc/http/server.ts, outside any page. The already-named/settingsshows about the same gap (about 1 ms in the one run I printed). So the test checks that the phases never exceedappand that the unattributed remainder is under 5 ms. Closing it to 1 ms would mean naming that server work, which I left out.To try it, sign in and request any of the three routes; the
Server-Timingheader lists the phases.Closes #4316