feat(labels): gitea_labels list hides numeric ids, so action:set cannot use its own output #7

New issue

Closed

opened 2026-10-23 17:33:35 +00:00 by dsh · 1 comment

dsh commented

2026-10-23 17:33:35 +00:00

Owner

Symptom

gitea_labels {action: "list"} prints only names:

area/dsh
needs-operator
priority/later
...

gitea_labels {action: "set"} accepts only numeric label ids (names are silently ignored — #6), so the tool's own list output cannot be used to perform the set. The DSH Bootcamp tells agents to "action: "list" first if you do not know them", which is currently impossible: the ids must be fetched from the REST API.

Observed 2026-10-23 on dsh-plugins/dsh-resend-mcp while adopting the label-at-creation policy. After creating type/bug, priority/now, area/forgejo:

gitea_labels {action:"list"} → names only, no ids.
GET /api/v1/repos/dsh-plugins/dsh-resend-mcp/labels?limit=100 → ids 39, 40, 41.
gitea_labels {action:"set", labels:[39,40,41]} → works.

This is the gap between #5 (bare OK) and #6 (no labels at creation): the one tool meant to provide ids for the workaround hides them.

Root cause

lib/handlers/formatters.js:205 — the generic array formatter has no labels branch:

const lines = data.slice(0, 20).map((item) => {
  if (item?.number != null) return `#${item.number} ${item.title || ''}`.trim()
  if (item?.path != null) return `${item.branch || ''} ${item.path}`.trim()
  if (item?.name != null) return item.name          // labels stop here
  return JSON.stringify(item)
})

A label object is {id, name, color, description, ...}; only name survives. The same slice(0, 20) also silently drops labels past row 20 (same defect class as #2).

Fix

Add a labels branch to the formatter: one line per label with name, numeric id and colour, e.g.
type/bug (id: 39, #e11d48) — Defect: wrong, missing or misleading behaviour.
Render all rows the API returned, or add an explicit "… and N more" footer (ties into #2).
Echo the created label and its id on create (ties into #5): Label "type/bug" created (id 39).
Consider accepting names in action: "set" by resolving them server-side/case-insensitively, which would remove the need for ids in the common case (overlaps #6).

Acceptance

gitea_labels {action:"list"} shows each label's numeric id.
a set using an id copied from the list output succeeds.
create reports the new label's id.
repos with >20 labels do not silently lose rows.

## Symptom `gitea_labels {action: "list"}` prints only names: ``` area/dsh needs-operator priority/later ... ``` `gitea_labels {action: "set"}` accepts **only numeric label ids** (names are silently ignored — #6), so the tool's own list output cannot be used to perform the set. The DSH Bootcamp tells agents to "`action: "list"` first if you do not know them", which is currently impossible: the ids must be fetched from the REST API. Observed 2026-10-23 on `dsh-plugins/dsh-resend-mcp` while adopting the label-at-creation policy. After creating `type/bug`, `priority/now`, `area/forgejo`: - `gitea_labels {action:"list"}` → names only, no ids. - `GET /api/v1/repos/dsh-plugins/dsh-resend-mcp/labels?limit=100` → ids 39, 40, 41. - `gitea_labels {action:"set", labels:[39,40,41]}` → works. This is the gap between #5 (bare `OK`) and #6 (no labels at creation): the one tool meant to provide ids for the workaround hides them. ## Root cause `lib/handlers/formatters.js:205` — the generic array formatter has no labels branch: ```js const lines = data.slice(0, 20).map((item) => { if (item?.number != null) return `#${item.number} ${item.title || ''}`.trim() if (item?.path != null) return `${item.branch || ''} ${item.path}`.trim() if (item?.name != null) return item.name // labels stop here return JSON.stringify(item) }) ``` A label object is `{id, name, color, description, ...}`; only `name` survives. The same `slice(0, 20)` also silently drops labels past row 20 (same defect class as #2). ## Fix - Add a labels branch to the formatter: one line per label with name, numeric id and colour, e.g. `type/bug (id: 39, #e11d48) — Defect: wrong, missing or misleading behaviour`. - Render all rows the API returned, or add an explicit "… and N more" footer (ties into #2). - Echo the created label and its id on `create` (ties into #5): `Label "type/bug" created (id 39)`. - Consider accepting names in `action: "set"` by resolving them server-side/case-insensitively, which would remove the need for ids in the common case (overlaps #6). ## Acceptance - [ ] `gitea_labels {action:"list"}` shows each label's numeric id. - [ ] a `set` using an id copied from the list output succeeds. - [ ] `create` reports the new label's id. - [ ] repos with >20 labels do not silently lose rows.

dsh added the

type/bug

area/forgejo

priority/next

labels

2026-10-23 17:33:37 +00:00

dsh referenced this issue from a commit

2026-10-23 18:05:07 +00:00

fix(tools): render complete lists and never print a bare OK

dsh referenced this issue from a pull request that will close it,

2026-10-23 18:05:11 +00:00

fix(tools): render complete lists and never print a bare OK #11

dsh closed this issue

2026-10-23 18:05:32 +00:00

dsh commented

2026-10-23 18:05:58 +00:00

Author

Owner

Fixed in 4d77e9f (fix(tools): render complete lists and never print a bare OK), merged to master (#11).

gitea_labels {action:"list"} now prints type/bug (id: 13, #e11d48) — Defect: …; create echoes Label "…" created (id N).; >100 labels get the visible footer; slimRecord keeps color/description for label-shaped records.

Live checks on this repo:

list ids match the REST API (area/forgejo=14, priority/next=15, priority/now=19, type/bug=13, type/task=42);
action:"set" on #8 with ids copied from that output succeeded and returned the labels rendered with ids.

#6 (labels/assignee/milestone at creation) stays separate, as scoped.

Fixed in 4d77e9f (`fix(tools): render complete lists and never print a bare OK`), merged to `master` (#11). `gitea_labels {action:"list"}` now prints `type/bug (id: 13, #e11d48) — Defect: …`; `create` echoes `Label "…" created (id N).`; >100 labels get the visible footer; `slimRecord` keeps `color`/`description` for label-shaped records. Live checks on this repo: - list ids match the REST API (area/forgejo=14, priority/next=15, priority/now=19, type/bug=13, type/task=42); - `action:"set"` on #8 with ids copied from that output succeeded and returned the labels rendered with ids. #6 (labels/assignee/milestone at creation) stays separate, as scoped.

dsh referenced this issue

2026-10-23 18:27:31 +00:00

feat(ci): publish tagged builds to the Forgejo npm registry; point the updater at it #12