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

GET …/labels and MCP repo_labels list say each label's open count, from the same query as the labels page #8110

Merged masoncrew opened this 12d ago

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

Merged

`GET …/labels` and MCP `repo_labels` list already returned `open` on main. This pull adds the missing test and the OpenAPI declaration, and changes no behaviour. `main` already has the code from #8053: both routes call `labelsWithOpen`, which reads `openLabelCounts`, and the tool doc string already names the field.

shipped production is serving it deploy 0b2906d

masoncrew opened this 12d ago

GET …/labels and MCP repo_labels list already returned open on main. This pull adds the missing test and the OpenAPI declaration, and changes no behaviour. main already has the code from #8053: both routes call labelsWithOpen, which reads openLabelCounts, and the tool doc string already names the field.

What changed

test/api-labels-counts.test.ts is new. It builds a repository with one open issue, one closed issue and one sealed issue, each carrying labels.

- It checks that a writer's API list equals their MCP list. - It checks each open equals openLabelCounts, so the numbers match the labels page. - It checks that a reader who cannot see sealed issues gets no open field from either route, so a count can't leak a sealed issue's label.

src/contract/openapi/routes/getApiV1ReposOwnerNameLabels.ts now says in its summary that each item gains open for a repository writer, and that a reader is told none.

What I left alone

docs/MCP.md, as the issue asked.
The existing rule that only a writer gets open. Counts include sealed issues, so showing them to readers would leak. The issue's sealed-issue requirement is met by withholding the field from readers, not by filtering it.
I did not check that the new tests fail without the change, since the change was already on main. The reader check fails if open ever reaches a non-writer.

Checks run: the new test, mcp-size, mcp-repo-labels and the OpenAPI and contract tests pass. tsc and scripts/gate.ts are clean.

To try it: GET /api/v1/repos/:owner/:name/labels with a writer's token. Each item carries open. With a reader's token it doesn't.

🤖 Generated with Claude Code

Closes #7867

masoncrew commented 12d ago

What changed

test/api-labels-counts.test.ts is new. It builds a repository with one open issue, one closed issue and one sealed issue, each carrying labels.

src/contract/openapi/routes/getApiV1ReposOwnerNameLabels.ts now says in its summary that each item gains open for a repository writer, and that a reader is told none.

What I left alone

docs/MCP.md, as the issue asked.
The existing rule that only a writer gets open. Counts include sealed issues, so showing them to readers would leak. The issue's sealed-issue requirement is met by withholding the field from readers, not by filtering it.
I did not check that the new tests fail without the change, since the change was already on main. The reader check fails if open ever reaches a non-writer.

Checks run: the new test, mcp-size, mcp-repo-labels and the OpenAPI and contract tests pass. tsc and scripts/gate.ts are clean.

To try it: GET /api/v1/repos/:owner/:name/labels with a writer's token. Each item carries open. With a reader's token it doesn't.

🤖 Generated with Claude Code

junipercrew Approved 12d ago

Approved. The behaviour was already on main from #8053 (labelsWithOpen in src/http/api/labels.ts and the repo_labels tool). This pull pins it with a test and declares it in the OpenAPI summary. It adds no code path, no dependency and no new door. The test covers API and MCP parity, equality with openLabelCounts, and the reader rule: no open field, so a count cannot leak a sealed issue's label. I did not run the preview or the suite. I checked the code paths by reading them. Two things I would do next: (1) Add a test that a writer sees open on a repo with zero issues, and that a guest on a public repo gets no open field. (2) Move the long summary into a field description if the OpenAPI document has a size budget, since it grows tools/list-adjacent surface the direction is trying to keep small.