Phil/forgejo-mcp
1
0
Fork 0
Code Issues 9 Pull requests 3 Projects Releases Packages Wiki Activity Actions

add_issue_labels should accept label names, not only numeric IDs #20

New issue
Open
opened 2026-09-12 13:27:03 +00:00 by Phil · 0 comments
Phil commented 2026-09-12 13:27:03 +00:00
Owner
Copy link

Symptom

mcp__forgejo_mcp__add_issue_labels rejects names outright:

add_issue_labels(owner="Philflow", repo="flow.raven", index=6553, labels="type/infra")
→ invalid label ID 'type/infra': strconv.ParseInt: parsing "type/infra": invalid syntax
  - labels must be numeric IDs

So every caller that knows a label by name has to resolve it first via list_repo_labels. That listing is paginated at 50 and sorted by name, which makes the resolve a multi-call walk — and a silent failure mode when the caller only gets one call.

Why it matters

It already cost a production behaviour. The auto-issue triage stage budgeted exactly one list_repo_labels call, so it saw one alphabetical slice of Philflow/flow.raven and could never reach type/*; every run fell back to type/unclear (Philflow/auto-issue-orchestrator#212, fixed there by raising the budget — a workaround for this).

Upstream supports names

Forgejo's POST /repos/{owner}/{repo}/issues/{n}/labels accepts label names. The caveat is that it silently drops names that do not exist on the repo — which is why callers pre-create (see flow.raven-deployment/apps/forgejo-alert-bridge/src/bridge/forgejo.py, attach_labels, documented from live verification on 2026-05-23). Note the neighbouring quirk: POST /issues with labels: ["name"] does 422 and wants IDs, so the two endpoints genuinely differ.

Proposed

Accept both in labels: pass numeric entries through as IDs, forward non-numeric entries as names. Because unknown names are dropped silently by the server, the tool should read back the issue's labels after the write and report any requested name that did not stick, rather than returning success.

Acceptance criteria

  • labels="type/infra" attaches the label.
  • labels="123" still works.
  • A name that does not exist on the repo produces an explicit error, not a silent no-op.
  • Consumers can drop their list_repo_labels resolve step.

🤖 Generated with Claude Code

## Symptom `mcp__forgejo_mcp__add_issue_labels` rejects names outright: ``` add_issue_labels(owner="Philflow", repo="flow.raven", index=6553, labels="type/infra") → invalid label ID 'type/infra': strconv.ParseInt: parsing "type/infra": invalid syntax - labels must be numeric IDs ``` So every caller that knows a label by name has to resolve it first via `list_repo_labels`. That listing is paginated at 50 and sorted by **name**, which makes the resolve a multi-call walk — and a silent failure mode when the caller only gets one call. ## Why it matters It already cost a production behaviour. The auto-issue triage stage budgeted exactly one `list_repo_labels` call, so it saw one alphabetical slice of `Philflow/flow.raven` and could never reach `type/*`; every run fell back to `type/unclear` (`Philflow/auto-issue-orchestrator#212`, fixed there by raising the budget — a workaround for this). ## Upstream supports names Forgejo's `POST /repos/{owner}/{repo}/issues/{n}/labels` accepts label **names**. The caveat is that it silently drops names that do not exist on the repo — which is why callers pre-create (see `flow.raven-deployment/apps/forgejo-alert-bridge/src/bridge/forgejo.py`, `attach_labels`, documented from live verification on 2026-05-23). Note the neighbouring quirk: `POST /issues` with `labels: ["name"]` does 422 and wants IDs, so the two endpoints genuinely differ. ## Proposed Accept both in `labels`: pass numeric entries through as IDs, forward non-numeric entries as names. Because unknown names are dropped silently by the server, the tool should read back the issue's labels after the write and report any requested name that did not stick, rather than returning success. ## Acceptance criteria - `labels="type/infra"` attaches the label. - `labels="123"` still works. - A name that does not exist on the repo produces an explicit error, not a silent no-op. - Consumers can drop their `list_repo_labels` resolve step. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
fix/actions-logs-api
feat/attachment-file-path
feat/merge-e2e-gate
ci/release-philflow
feat/runs-jobs-artifacts-tools
feat/run-logs
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Phil/forgejo-mcp#20
No description provided.