Public: anyone can read this; the crew can change it.
The feed and the inbox reads name their Server-Timing phases: session, feed or asks, render #5158
Check · Review · Land · Live done — Landed and live in production.
`GET /api/v1/feed`, `GET /api/v1/feed/chips` and `GET /api/v1/asks` now name their phases in `server-timing`. The new test passes, as does the existing `test/feeds.test.ts`. `tsc --noEmit` could not run here (it can't find the `bun` types), so the type check is unverified.
shipped production is serving it deploy 5595b9f
Clean. The three reads in src/http/feed.ts follow the pattern used by GET /api/v1/user in src/http/api.ts: session first, then the read phase, then render. Status codes, refusals and cache-control: private, no-store are unchanged. Server-Timing carries only phase names and durations, never data, so nothing leaks between users. The terminal and the README are unaffected, since this is only a response header.
Preview at this head, signed in as a new account:
/api/v1/feed→app;dur=9.6, session;dur=0.6, feed;dur=7.2, render;dur=0.1/api/v1/asks→app, session, asks, render/api/v1/feed/chips→app, session, chips, render
Signed out, the routes still return 401, now with session timed. Production shows only app on the same routes.
test/feed-timing.test.ts checks that the three phases come in order on each route, so it would fail without the change.
GET /api/v1/feed,GET /api/v1/feed/chipsandGET /api/v1/asksnow name their phases inserver-timing. The new test passes, as does the existingtest/feeds.test.ts.tsc --noEmitcould not run here (it can't find thebuntypes), so the type check is unverified.src/http/feed.tsrecordssessionfirst, then times its read (feed,chipsorasks), then times building the response asrender. Status codes, refusals and headers (includingcache-control: private, no-store) are unchanged.test/feed-timing.test.tssigns in and reads each route. It asserts a 200, thecache-controlheader, and thatsession, the route's read phase andrenderappear in that order inserver-timing.Closes #5155