Public: anyone can read this; the crew can change it.
The API's apps list names its Server-Timing phases: session, apps, render #4953
Check · Review · Land · Live done — Landed and live in production.
`GET /api/v1/apps` now sends a Server-Timing header naming `session`, `apps` and `render`, in that order, as the branches list does. The new test passes and the type check is clean. I did not run the rest of the suite.
shipped production is serving it deploy 76ab860
GET /api/v1/apps now sends a Server-Timing header naming session, apps and render, in that order, as the branches list does. The new test passes and the type check is clean. I did not run the rest of the suite.
src/http/api.ts: only theGET /api/v1/appshandler changed. It notessessionwithtakeSessionTime, wraps the list, repo and runtime reads and the readability filter in anappsphase, and wraps the response inrender. The body is the same{ items, next_cursor: null }.test/api-apps-timing.test.ts: this new test follows the branches timing test. It requests/api/v1/appsand asserts the phase names equal["session", "apps", "render"], so dropping or reordering a phase fails it. It also checks thatitemsis an array.
I left out any timing split inside the apps phase. The other handlers in src/http/api.ts are untouched.
To try it, run curl -si <url>/api/v1/apps and read the server-timing header.
Clean. GET /api/v1/apps now names session, apps and render in the same way as the boards, branches and search handlers around it in src/http/api.ts. The body is still { items, next_cursor: null }, and the canRead filter is unchanged inside the apps phase, so a guest still sees only readable repos' apps. No write, no new input, nothing new in the output. The new test fails if any phase is dropped or reordered. The preview answers 200 with server-timing: app;dur=2.6, session;dur=0.1, apps;dur=0.2, render;dur=0.1 and the same JSON shape. Nothing changes for the terminal, so neither door is affected.
GET /api/v1/appsnow sends a Server-Timing header namingsession,appsandrender, in that order, as the branches list does. The new test passes and the type check is clean. I did not run the rest of the suite.src/http/api.ts: only theGET /api/v1/appshandler changed. It notessessionwithtakeSessionTime, wraps the list, repo and runtime reads and the readability filter in anappsphase, and wraps the response inrender. The body is the same{ items, next_cursor: null }.test/api-apps-timing.test.ts: this new test follows the branches timing test. It requests/api/v1/appsand asserts the phase names equal["session", "apps", "render"], so dropping or reordering a phase fails it. It also checks thatitemsis an array.I left out any timing split inside the
appsphase. The other handlers insrc/http/api.tsare untouched.To try it, run
curl -si <url>/api/v1/appsand read theserver-timingheader.Closes #4929