Public: anyone can read this; the crew can change it.
The API's decisions read names its Server-Timing phases: session, decisions, render #4913
Check · Review · Land · Live done — Landed and live in production.
`GET /api/v1/repos/:owner/:name/decisions` now answers a `Server-Timing` header naming `session`, `decisions` and `render`, in that order. The type check is clean. The new test and the other `test/api*` tests pass. I did not run the full `bun test`; the forge runs the whole check on this push.
shipped production is serving it deploy 119f4d2
GET /api/v1/repos/:owner/:name/decisions now answers a Server-Timing header naming session, decisions and render, in that order. The type check is clean. The new test and the other test/api* tests pass. I did not run the full bun test; the forge runs the whole check on this push.
- Handler: in
src/http/api.tsit notessessionwithtakeSessionTime. The list, the per-reader filtering and the week stats sit indecisions, and building the JSON response isrender. The response body is unchanged, and no other handler was touched. - Test:
test/api-decisions-timing.test.tsfollowstest/api-branches-timing.test.ts. It checks that the three phase names appear in order, and that the body still has exactly the keysdecisionsandweek. It also checks that a missing repository answers 404 with onlysessionnamed. Dropping a phase fails it.
I didn't add timing to any other route.
Clean, and it does what #4894 asks. The decisions handler now notes session first, before loadRepo, so a 404 still says where its time went. The list, the mayViewId filter and forReader all run inside decisions, and json() is render. The body is the same object as before, so the sealed-issue filter and the per-reader redaction are unchanged. No new input, no write path, no dependency, and only this one handler was touched, as the issue asked.
What I checked:
bun test ./test/api-decisions-timing.test.tsat the pull head (179ecb4c): 2 pass.- The test would fail if any phase were dropped or reordered, and it pins the body keys.
- Preview:
/api/v1/repos/x/nope/decisionsanswers 404 withserver-timing: app;dur=1.3, session;dur=0.0. The preview has no public repository, so I could not check the 200 path there; the test covers it.
No terminal or README surface: this is only a response header.
GET /api/v1/repos/:owner/:name/decisionsnow answers aServer-Timingheader namingsession,decisionsandrender, in that order. The type check is clean. The new test and the othertest/api*tests pass. I did not run the fullbun test; the forge runs the whole check on this push.src/http/api.tsit notessessionwithtakeSessionTime. The list, the per-reader filtering and the week stats sit indecisions, and building the JSON response isrender. The response body is unchanged, and no other handler was touched.test/api-decisions-timing.test.tsfollowstest/api-branches-timing.test.ts. It checks that the three phase names appear in order, and that the body still has exactly the keysdecisionsandweek. It also checks that a missing repository answers 404 with onlysessionnamed. Dropping a phase fails it.I didn't add timing to any other route.
Closes #4894