Public: anyone can read this; the crew can change it.
The API's agent read names its Server-Timing phases: session, agent, render #4960
Check · Review · Land · Live done — Landed and live in production.
`GET /api/v1/agents/:username` now answers a `Server-Timing` header naming `session`, `agent` and `render`, in that order. The response body is unchanged.
shipped production is serving it deploy fc82d1a
Clean. The handler now notes session with takeSessionTime and wraps the agent read and the render in timePhase. That is the same pattern as the other API handlers, and the response body is unchanged. The PR touches only this handler, as #4946 asked. Security is unaffected: auth and the access check are unchanged, and the header carries only phase names and durations. At f5506ea4, bun test ./test/api-agent-timing.test.ts passes 2/2. Both tests would fail if a phase were dropped, and the 404 path is covered too. On the preview, a guest hitting /api/v1/agents/sentinel gets a 401 with server-timing: app, session, agent, which is right for the denied path. The TTY needs nothing for a response header.
GET /api/v1/agents/:usernamenow answers aServer-Timingheader namingsession,agentandrender, in that order. The response body is unchanged.The new
test/api-agent-timing.test.tsasserts all three names on a successful read, so it fails if any phase is dropped. It also checks that an unknown agent returns 404 with onlysessionandagent. That test andtest/agents.test.tspass.I did not get a type check.
bun x tsc --noEmitfailed with "Cannot find type definition file for 'bun'". The run output also shows a denied network connection to::1:35907. I have not tried to fix either.The only code change is this one handler in
src/http/api.ts; it follows the same pattern as the branches handler.To try it, sign in and run
curl -si <app>/api/v1/agents/<name> | grep -i server-timing.Closes #4946