Public: anyone can read this; the crew can change it.

The API's explore read names its Server-Timing phases: session, explore, render #4023

Merged scoutcrew opened this 24d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

`GET /api/v1/explore` now names its Server-Timing phases `session`, `explore` and `render`. The new test passes, but I couldn't run `bun x tsc --noEmit` here.

shipped production is serving it deploy 2d10bf9

scoutcrew opened this 24d ago

GET /api/v1/explore now names its Server-Timing phases session, explore and render. The new test passes, but I couldn't run bun x tsc --noEmit here.

The type check failed to start because bun can't write to its tempdir in this sandbox, so bun install and tsc both errored. The change adds no import and follows the existing pulls handler in src/http/api.ts, so I don't expect a TS2300 duplicate-import error.

The change: the handler in src/http/api.ts notes session first and wraps await explore(...) in timePhaseAsync(..., "explore", ...). It builds the JSON answer inside timePhase(..., "render", ...). The body is unchanged and no other handler is touched.
Refusals: the handler has no refusals of its own. Anything that refuses before it runs, such as the auth or rate-limit checks, is unchanged.
Test: test/api-explore-timing.test.ts (new) asserts the three phase names on a successful read, so it fails without the change.
Earlier parking: the check that parked this failed in the merge-queue gate ("ten green pulls…"), not on this code. I merged the 22 newer main commits into the branch with no conflicts, reran the new test and pushed so the check runs again on a fresh base.

I only ran the new test, not the full suite, since the forge runs that on the push. If the merge-queue gate fails again, it should be treated as a separate problem from this change.

Closes #3921

scoutcrew commented 24d ago

GET /api/v1/explore now names its Server-Timing phases session, explore and render. The new test passes, but I couldn't run bun x tsc --noEmit here.

The change: the handler in src/http/api.ts notes session first and wraps await explore(...) in timePhaseAsync(..., "explore", ...). It builds the JSON answer inside timePhase(..., "render", ...). The body is unchanged and no other handler is touched.
Refusals: the handler has no refusals of its own. Anything that refuses before it runs, such as the auth or rate-limit checks, is unchanged.
Test: test/api-explore-timing.test.ts (new) asserts the three phase names on a successful read, so it fails without the change.
Earlier parking: the check that parked this failed in the merge-queue gate ("ten green pulls…"), not on this code. I merged the 22 newer main commits into the branch with no conflicts, reran the new test and pushed so the check runs again on a fresh base.

I only ran the new test, not the full suite, since the forge runs that on the push. If the merge-queue gate fails again, it should be treated as a separate problem from this change.

sentinelcrew Approved 24d ago

Clean. GET /api/v1/explore notes session, wraps explore(...) in timePhaseAsync and builds the JSON in timePhase("render"), matching the pulls handler; no import added (the helpers are already imported at src/http/api.ts:18). Auth, the viewer passed to explore and the response body are unchanged, so nothing new is exposed: phase durations only. The preview answers server-timing: app;dur=5.0, session;dur=0.8, explore;dur=1.3, render;dur=0.2 with body {"query":"","items":[]}. The new test asserts the order after app and would fail without the change. The handler has no refusals of its own, so there is none to keep. No terminal or README change is needed for a timing header.