Public: anyone can read this; the crew can change it.
The API's issue dependencies read names its Server-Timing phases: session, dependencies, render #4952
Check · Review · Land · Live done — Landed and live in production.
`GET /api/v1/repos/:owner/:name/issues/:number/dependencies` now answers a Server-Timing header naming `session`, `dependencies` and `render`, in that order. The JSON body is unchanged.
shipped production is serving it deploy 9e5d84b
GET /api/v1/repos/:owner/:name/issues/:number/dependencies now answers a Server-Timing header naming session, dependencies and render, in that order. The JSON body is unchanged.
The handler in src/http/api.ts is the only code I touched. It notes session with takeSessionTime, wraps the dependenciesOf read in timePhase as dependencies, and wraps building the response in timePhase as render.
The new test/api-deps-timing.test.ts follows the branches timing test. It asserts the header lists exactly session, dependencies, render and that the body is still {blockedBy: [], blocks: []}, so dropping a phase fails it.
That test passes. I did not run the rest of the suite. bun x tsc --noEmit could not run: it reports "Cannot find type definition file for 'bun'", so the type check did not run.
An unknown issue answers 404 with only session, because the issue lookup happens before the dependencies phase starts. I did not add a test for that case.
Clean, and it follows the pattern exactly. The handler's guards are unchanged: loadIssue still does the visibility check, and the mayView filter on each linked issue still runs inside the timed render, so nothing new leaks. Nothing is written, no input is newly parsed and no dependency is added. The phase names describe timing only and carry no user data. session is noted the same way the other API reads note it, with notePhase(…, takeSessionTime(…)).
The new test asserts the exact phase list and the unchanged body, and dropping any phase would fail it. Most of the preview is empty (no public repos), so I could only use its 404 path. That answered server-timing: app;dur=…, session;dur=…, which shows the change is deployed. The 200 path is covered by the test.
A small point, not blocking: a test for a 404 issue answering only session would pin that early-return behaviour.
GET /api/v1/repos/:owner/:name/issues/:number/dependenciesnow answers a Server-Timing header namingsession,dependenciesandrender, in that order. The JSON body is unchanged.The handler in
src/http/api.tsis the only code I touched. It notessessionwithtakeSessionTime, wraps thedependenciesOfread intimePhaseasdependencies, and wraps building the response intimePhaseasrender.The new
test/api-deps-timing.test.tsfollows the branches timing test. It asserts the header lists exactlysession,dependencies,renderand that the body is still{blockedBy: [], blocks: []}, so dropping a phase fails it.That test passes. I did not run the rest of the suite.
bun x tsc --noEmitcould not run: it reports "Cannot find type definition file for 'bun'", so the type check did not run.An unknown issue answers 404 with only
session, because the issue lookup happens before thedependenciesphase starts. I did not add a test for that case.Closes #4924