Public: anyone can read this; the crew can change it.
GET /api/v1/passport/health names its Server-Timing phases: session, read #5325
Check · Review · Land · Live done — Landed and live in production.
`GET /api/v1/passport/health` now names two Server-Timing phases, `session` and `read`, so a slow check shows which side is slow.
shipped production is serving it deploy 6a8e95d
GET /api/v1/passport/health now names two Server-Timing phases, session and read, so a slow check shows which side is slow.
- What changed: In
src/http/passport_edge.ts,sessiontimes the passport verification andreadtimesreadHealth, both withtimePhase. A refused passport emitssessiononly, since it never reaches the read. The response body, status codes and headers are unchanged. - Test: The new
test/passport-health-timing.test.tschecks that a good passport getssession, readin that order and a refused one getssessiononly. I didn't run it against the old handler to watch it fail, but the old handler named neither phase. - Checks run: The new test and
test/passport-edge.test.tspass (5 tests), andbun x tsc --noEmitis clean. I did not run the full suite; the forge's check does that on push.
Here session means passport verification, not the browser session that api.ts times under the same name. I kept the name because the issue asks for it.
To try it, call the route with a valid Authorization: Passport … header and read the server-timing response header.
🤖 Generated with Claude Code
Clean. This adds timing only. Auth is still read from the Authorization: Passport header and checked by verify with the same audience and scope, and the refusal path, body, status and headers have not changed. I ran the new test and test/passport-edge.test.ts against the pull head: 5 pass. With the base handler swapped back in, the new test fails 2 of 2, so it does test this change. In the preview, an unauthenticated request and a bogus passport both get 401 with server-timing: app;dur=…, session;dur=… and nothing from the read phase, and the security headers are still there. The only thing a refused caller learns is how long verification took, which the response time already shows. The terminal and README don't apply to a header-only change. This is what #5312 asked for.
GET /api/v1/passport/healthnow names two Server-Timing phases,sessionandread, so a slow check shows which side is slow.src/http/passport_edge.ts,sessiontimes the passport verification andreadtimesreadHealth, both withtimePhase. A refused passport emitssessiononly, since it never reaches the read. The response body, status codes and headers are unchanged.test/passport-health-timing.test.tschecks that a good passport getssession, readin that order and a refused one getssessiononly. I didn't run it against the old handler to watch it fail, but the old handler named neither phase.test/passport-edge.test.tspass (5 tests), andbun x tsc --noEmitis clean. I did not run the full suite; the forge's check does that on push.Here
sessionmeans passport verification, not the browser session thatapi.tstimes under the same name. I kept the name because the issue asks for it.To try it, call the route with a valid
Authorization: Passport …header and read theserver-timingresponse header.🤖 Generated with Claude Code
Closes #5312