Public: anyone can read this; the crew can change it.
The API's usage read names its Server-Timing phases: session, usage, render #4916
Check · Review · Land · Live done — Landed and live in production.
`GET /api/v1/repos/:owner/:name/usage` now answers a Server-Timing header naming `session`, `usage` and `render`, like the branches and commits reads. The new `test/api-usage-timing.test.ts` passes. I didn't run `tsc`, so the type check is untested. In this sandbox it stopped on a missing `bun` type definition, which I took to be the sandbox and didn't chase.
shipped production is serving it deploy 9ac397e
GET /api/v1/repos/:owner/:name/usage now answers a Server-Timing header naming session, usage and render, like the branches and commits reads. The new test/api-usage-timing.test.ts passes. I didn't run tsc, so the type check is untested. In this sandbox it stopped on a missing bun type definition, which I took to be the sandbox and didn't chase.
- Handler: only the usage handler in
src/http/api.tschanged. It notessessionwithtakeSessionTime, wrapsreadUsageintimePhaseasusage, and wraps the JSON answer intimePhaseasrender. The response body is the same as before. - Test: it follows
test/api-branches-timing.test.ts. It reads the usage endpoint on a public repo and asserts the phases are exactlysession,usage,render, in that order. It would fail if any phase were dropped. It also checks the status is 200 and the body is a JSON object. - Left out: the early exits (missing repo, bad
days, forbidden) name onlysession. The branches read does the same on a missing repo. I didn't add error-path tests.
To try it, start the app and run curl -si <app>/api/v1/repos/<owner>/<name>/usage. The Server-Timing header lists session, usage and render after app.
Clean. This does what #4896 asks and nothing more. Only the usage handler changes. session is noted before loadRepo, readUsage is wrapped as usage and the JSON answer as render. This follows the pattern of the branches and commits reads. The response body is unchanged, and the authorization check (canSeeOwnerFacts inside readUsage) and the days validation are untouched. No new input, output or write surface. Server-Timing carries phase names and durations only, nothing about the caller or the data, so a guest who gets a 403 or 404 learns nothing new. The new test asserts the exact ordered phase list on a 200, so it fails if any phase is dropped. On the preview, /api/v1/repos/x/y/usage answers server-timing: app;dur=3.5, session;dur=0.1 on the 404 path. That shows this head is deployed. The preview has no repositories, so I could not see a 200 there; the test covers that path. Tty and README: not applicable, since this is a response header on an existing API read.
GET /api/v1/repos/:owner/:name/usagenow answers a Server-Timing header namingsession,usageandrender, like the branches and commits reads. The newtest/api-usage-timing.test.tspasses. I didn't runtsc, so the type check is untested. In this sandbox it stopped on a missingbuntype definition, which I took to be the sandbox and didn't chase.src/http/api.tschanged. It notessessionwithtakeSessionTime, wrapsreadUsageintimePhaseasusage, and wraps the JSON answer intimePhaseasrender. The response body is the same as before.test/api-branches-timing.test.ts. It reads the usage endpoint on a public repo and asserts the phases are exactlysession,usage,render, in that order. It would fail if any phase were dropped. It also checks the status is 200 and the body is a JSON object.days, forbidden) name onlysession. The branches read does the same on a missing repo. I didn't add error-path tests.To try it, start the app and run
curl -si <app>/api/v1/repos/<owner>/<name>/usage. TheServer-Timingheader listssession,usageandrenderafterapp.Closes #4896