The API's origin repository list names its Server-Timing phases: session, origin, render #3931

GET /api/v1/user/origins/:id/repos now names its Server-Timing phases: session, then origin, then render. A successful read shows all three, and bun x tsc --noEmit is clean. I ran only the new test and test/origins.test.ts, which pass. I did not run the full bun test; the forge's check runs that on the push.

• Handler (src/http/api.ts, this handler only, no new import): it notes session first, before the access check, so refusals name it too. listRemoteRepos runs inside timePhaseAsync(..., "origin", ...), and the JSON answer is built inside timePhase(..., "render", ...).
• Refusals: the 404, 422, 429 and 502 origin_unreachable answers keep their status and body. The 502 and the 404 for an unknown origin name session and origin. A refusal at the access check names only session. I did not add a test for the 422 or 429 refusals.
• Test (test/api-origin-repos-timing.test.ts, new): it connects a fake Forgejo origin and asserts the phase names for the success, 404 and 502 cases. It reaches no real host. All three assertions fail without the handler change.
• 502 test setup: listRemoteRepos serves cached rows when the origin fails, so the 502 test clears the cache table (origin_repo) first.

To try it, request /api/v1/user/origins/<id>/repos?refresh=1 with an account credential and read the Server-Timing header.

🤖 Generated with Claude Code

Closes #3923

GET /api/v1/user/origins/:id/repos now names its Server-Timing phases: session, then origin, then render. A successful read shows all three, and bun x tsc --noEmit is clean. I ran only the new test and test/origins.test.ts, which pass. I did not run the full bun test; the forge's check runs that on the push.

• Handler (src/http/api.ts, this handler only, no new import): it notes session first, before the access check, so refusals name it too. listRemoteRepos runs inside timePhaseAsync(..., "origin", ...), and the JSON answer is built inside timePhase(..., "render", ...).
• Refusals: the 404, 422, 429 and 502 origin_unreachable answers keep their status and body. The 502 and the 404 for an unknown origin name session and origin. A refusal at the access check names only session. I did not add a test for the 422 or 429 refusals.
• Test (test/api-origin-repos-timing.test.ts, new): it connects a fake Forgejo origin and asserts the phase names for the success, 404 and 502 cases. It reaches no real host. All three assertions fail without the handler change.
• 502 test setup: listRemoteRepos serves cached rows when the origin fails, so the 502 test clears the cache table (origin_repo) first.

To try it, request /api/v1/user/origins/<id>/repos?refresh=1 with an account credential and read the Server-Timing header.

🤖 Generated with Claude Code

The full gate on land was red and named no test; the pull is open again.

The origin repository list's Server-Timing header now names session, origin and render, as before. This push only merges current main into the branch.

I couldn't see why the full gate failed, because the failure named no test. The branch was based on an older main, so I merged main in rather than rebasing, since force pushes are refused. After the merge:

• bun x tsc --noEmit is clean.
• bun test test/api-origin-repos-timing.test.ts passes (3 tests).

I didn't re-run the whole gate here, so whether this clears it depends on the forge's check on this push. If it is still red, the log should say what failed.

The change itself:

• session is noted before the access gate, so a 401 also carries it.
• origin times the lookup.
• render times building the JSON.
• The 404 and 502 bodies and the JSON response are unchanged, and there are no new dependencies.

To try it, send GET /api/v1/user/origins/x/repos and read the server-timing header.

The full gate on land was red and named no test; the pull is open again.

GET /api/v1/user/origins/:id/repos still names its Server-Timing phases session, origin and render. I found nothing in the change that could fail the gate, and this push only merges main in again.

The gate failure named no test, and I couldn't see its log. The branch was behind main again, so I merged the latest main and pushed. After the merge:

• bun scripts/gate.ts prints nothing.
• bun x tsc --noEmit is clean.
• test/api-origin-repos-timing.test.ts and test/origins.test.ts pass (33 tests).

I did not run the full test suite here. If the gate is still red on this push, its log should say which test failed, and I'll fix it from there.

What the change does:

• session is noted before the access gate, so a 401 carries it too.
• origin times the listRemoteRepos call.
• render times building the JSON.
• The 404 and 502 bodies and the JSON response are unchanged, and there are no new dependencies.

To try it, send GET /api/v1/user/origins/<id>/repos?refresh=1 with an account credential and read the server-timing header.

The full gate on land was red and named no test; the pull is open again.

The last check failed because the npm registry refused the package downloads with 429, not because of this change. The log shows the check's egress was already at its cap of 8 connections to registry.npmjs.org, and bun install failed on @types/node. The change is still only src/http/api.ts and test/api-origin-repos-timing.test.ts. It touches no package.json or lockfile, so I had no code or dependency fix to make.

I pushed an empty commit so the check runs again. Locally, tsc is clean and test/api-origin-repos-timing.test.ts and test/origins.test.ts pass (33 tests). I did not run the full suite here. If the registry throttles the next install too, the cause is the egress cap on the check's install step, and that needs a person.

What the pull changes: GET /api/v1/user/origins/:id/repos now names its Server-Timing phases session, origin and render. session is noted before the access gate, so a 401 carries it too. The 404 and 502 bodies and the JSON response are unchanged, and there are no new dependencies.

To try it, request /api/v1/user/origins/<id>/repos?refresh=1 with an account credential and read the server-timing header.

Parked by the crew: the check failed in the place it ran, not in the change, and failed the same way when it was run again