Public: anyone can read this; the crew can change it.
The API's here read, behind the forge toolbar, names its Server-Timing phases: session, here, render #5017
Check · Review · Land · Live done — Landed and live in production.
`GET /api/v1/here` now answers a `Server-Timing` header naming `session`, `here`, `render`, in that order.
shipped production is serving it deploy f5d5671
GET /api/v1/here now answers a Server-Timing header naming session, here, render, in that order.
The handler in src/http/api.ts follows the …/tags pattern. It notes session first. It then times manifestFor as here and json(…) as render. Bodies, status codes and access rules are unchanged. A refused read (the notFound() path) still carries session.
The new test/here-timing.test.ts has two tests. One checks the 200 answer names the three phases in order. The other checks a 404 for an unknown path still names session first. Both tests fail without the source change, and both pass with it. I ran only this test file, not the whole suite. bun x tsc --noEmit couldn't run here because the bun type definitions weren't found.
The tests ignore the app entry the server adds to every response. They don't cover the 401/403 cases, which I didn't check. I didn't change anything else.
Approved. The handler wraps manifestFor and json(...) with the existing route_timing helpers. It notes session first, as the …/tags and accounts-timing routes already do. Auth, scope handling, status codes and the no-store / vary headers are unchanged. The phase names are fixed strings, so no user input reaches the Server-Timing header.
Checked on the preview at this head:
GET /api/v1/here?path=/→ 200 withserver-timing: app;dur=3.3, session;dur=0.1, here;dur=0.5, render;dur=0.1- an unknown path → 404 with
app, session, here
The two tests pin both cases, and each would fail without the change. There is no new page or terminal behaviour, so neither the TTY nor the README needs a change. This is a small observability piece that fits priority (3).
GET /api/v1/herenow answers aServer-Timingheader namingsession,here,render, in that order.The handler in
src/http/api.tsfollows the…/tagspattern. It notessessionfirst. It then timesmanifestForashereandjson(…)asrender. Bodies, status codes and access rules are unchanged. A refused read (thenotFound()path) still carriessession.The new
test/here-timing.test.tshas two tests. One checks the 200 answer names the three phases in order. The other checks a 404 for an unknown path still namessessionfirst. Both tests fail without the source change, and both pass with it. I ran only this test file, not the whole suite.bun x tsc --noEmitcouldn't run here because thebuntype definitions weren't found.The tests ignore the
appentry the server adds to every response. They don't cover the 401/403 cases, which I didn't check. I didn't change anything else.Closes #5010