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

A repository's label routes leave api.ts for src/http/api/labels.ts #6931

Merged opened this

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

Merged

The repository's three label routes now live in their own module, `src/http/api/labels.ts`, and behave exactly as before: `GET` and `POST` on `/api/v1/repos/:owner/:name/labels`, and `DELETE` on `…/labels/:id`. The new file exports `labelsRoutes(router)`. In `src/http/api.ts`, `apiRoutes` calls it on one line where the routes used to be, under the existing `── labels` header, so the diff there is…

shipped production is serving it deploy 6a8e95d

opened this

The repository's three label routes now live in their own module, src/http/api/labels.ts, and behave exactly as before: GET and POST on /api/v1/repos/:owner/:name/labels, and DELETE on …/labels/:id. The new file exports labelsRoutes(router). In src/http/api.ts, apiRoutes calls it on one line where the routes used to be, under the existing ── labels header, so the diff there is one removal and one added line.

  • Imports: createLabel, deleteLabel and listLabels were only used by these routes, so their imports moved out of api.ts with them. loadRepo is imported from ../api.ts, the same way api/egress_grants.ts already does it. Nothing was copied.
  • Left in place: the per-issue and per-pull label routes (…/issues/:number/labels, …/pulls/:number/labels) and the labels read under BROWSE stay in api.ts. They set an issue's or pull's labels, not the repository's list, and the issue covers only the three routes above.
  • Checked: bun x tsc --noEmit is clean. The 11 test files that call these routes or the label code pass unchanged: 107 pass, 0 fail. They include api-list-shape, parity, repo-reads-timing, origins*, settings, label-words, mcp-labels and mcp-repo-labels. No file under src/web/ changed, so the design lint wasn't needed.

To try it, run curl $PREVIEW/api/v1/repos/<owner>/<name>/labels and compare with production: the answer should be the same.

🤖 Generated with Claude Code

Closes #6303

commented

The repository's three label routes now live in their own module, src/http/api/labels.ts, and behave exactly as before: GET and POST on /api/v1/repos/:owner/:name/labels, and DELETE on …/labels/:id. The new file exports labelsRoutes(router). In src/http/api.ts, apiRoutes calls it on one line where the routes used to be, under the existing ── labels header, so the diff there is one removal and one added line.

  • Imports: createLabel, deleteLabel and listLabels were only used by these routes, so their imports moved out of api.ts with them. loadRepo is imported from ../api.ts, the same way api/egress_grants.ts already does it. Nothing was copied.
  • Left in place: the per-issue and per-pull label routes (…/issues/:number/labels, …/pulls/:number/labels) and the labels read under BROWSE stay in api.ts. They set an issue's or pull's labels, not the repository's list, and the issue covers only the three routes above.
  • Checked: bun x tsc --noEmit is clean. The 11 test files that call these routes or the label code pass unchanged: 107 pass, 0 fail. They include api-list-shape, parity, repo-reads-timing, origins*, settings, label-words, mcp-labels and mcp-repo-labels. No file under src/web/ changed, so the design lint wasn't needed.

To try it, run curl $PREVIEW/api/v1/repos/<owner>/<name>/labels and compare with production: the answer should be the same.

🤖 Generated with Claude Code

Approved

Clean move. The three handlers in src/http/api/labels.ts match the removed block line for line: GET still goes through loadRepo, so visibility is unchanged and a private or unknown repo gives the same 404. POST and DELETE still check requireScope(ctx, "admin") before anything else, and createLabel/deleteLabel in actions/repos.ts still decide who may write. The body is still read through respond.ts's body(), so the byte cap is unchanged. loadRepo comes from ../api.ts the same way api/egress_grants.ts does it. The three imports that moved were used only here, and nothing dead is left behind.

On the preview at this head, GET /api/v1/repos/trevato/forge/labels returns 404 not_found; the preview holds no repositories, and production gives the same answer for a repo it can't see. A guest's POST …/labels and DELETE …/labels/1 both get 401, so the write doors are still gated. The routes add no new behaviour, so no new test is owed. The existing label suites (mcp-labels, mcp-repo-labels, parity, api-list-shape) cover these routes. It is small and does one thing, which fits the api.ts split (#6303). The page, the MCP and the tty are untouched.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs