Tool bugs seen from issue-tracker work (2026-10-23): wiki get, repo contents, issue pagination, empty responses, label assignment #1

New issue

Closed

opened 2026-10-23 17:02:04 +00:00 by dsh · 2 comments

dsh commented

2026-10-23 17:02:04 +00:00

Owner

Found while bootstrapping pvlb-infra/issue-tracker (2026-10-23) — reproduced against the live Forgejo 17.0.0 as user dsh. Logged here so the next agent does not re-debug them; the same list lives in issue-tracker/AGENTS.md under Tool bugs.

1. `gitea_wiki get` returns only `OK`

Repro: gitea_wiki {action: "get", owner: "pvlb-infra", repo: "vps-setup", pageName: "Home"} → OK. The page exists (a wiki-repo clone contains Home.md).
Expected: the page markdown.
Workaround: git clone ssh://git@git.pvlb.dev/pvlb-infra/vps-setup.wiki.git. Already documented in the DSH Bootcamp wiki page, so this is the known occurrence.

2. `gitea_repo_contents` returns the filename, not the contents

Repro: owner: pvlb-infra, repo: vps-setup, path: AGENTS.md → AGENTS.md; owner: web, repo: web-frontend, path: README.md → README.md.
Expected: the file body (it is the "contents" tool).
Also: path: "" fails with gitea_repo_contents failed: invalid owner, repo, or filePath, so directories cannot be listed either.
Workaround: clone the repo, or GET /api/v1/repos/{owner}/{repo}/contents/{path} with GITEA_TOKEN.

3. `gitea_issue_list` silently truncates when `limit > 20`

On pvlb-infra/vps-setup (28 issues, state=all):

call	result
`limit: 5, page: 1`	5 rows (fine)
`limit: 100, page: 1`	20 rows
`limit: 50, page: 1`	20 rows
`limit: 50, page: 2`	`OK` (empty) — but issues #9–#2 remain
`limit: 20, page: 2`	8 rows (fine)

Looks like the page size is clamped to 20 but the offset is still (page - 1) * limit, so page 2+ is skipped silently. A naive "list everything" call misses 8 of 28 issues in a single repo — exactly the failure mode a cross-project digest cannot afford.

Workaround: always pass limit <= 20, then page through.

4. Empty results render as a bare `OK`

Repro: gitea_issue_list on pvlb-infra/issue-tracker or pvlb-infra/forge-runner (0 issues) → OK. Same for gitea_labels list on a repo without labels, and gitea_labels create on success.
Expected: [], "no issues", or the created object — right now "empty" and "it worked" are indistinguishable without a second query.

Verified not broken

owner/repo/state filtering is correct (t14-deeps open → 5 rows; dsh-resend-mcp all → 7 rows).
Issue numbers are repo-scoped, as expected.

Acceptance

gitea_wiki get returns the page body.
gitea_repo_contents returns file content (and either supports directory listing or says so in its description).
gitea_issue_list honours limit up to the server max and paginates consistently.
Empty result sets are explicit, not OK.

Found while bootstrapping `pvlb-infra/issue-tracker` (2026-10-23) — reproduced against the live Forgejo 17.0.0 as user `dsh`. Logged here so the next agent does not re-debug them; the same list lives in `issue-tracker/AGENTS.md` under *Tool bugs*. ## 1. `gitea_wiki get` returns only `OK` - **Repro:** `gitea_wiki {action: "get", owner: "pvlb-infra", repo: "vps-setup", pageName: "Home"}` → `OK`. The page exists (a wiki-repo clone contains `Home.md`). - **Expected:** the page markdown. - **Workaround:** `git clone ssh://git@git.pvlb.dev/pvlb-infra/vps-setup.wiki.git`. Already documented in the *DSH Bootcamp* wiki page, so this is the known occurrence. ## 2. `gitea_repo_contents` returns the filename, not the contents - **Repro:** `owner: pvlb-infra, repo: vps-setup, path: AGENTS.md` → `AGENTS.md`; `owner: web, repo: web-frontend, path: README.md` → `README.md`. - **Expected:** the file body (it is the "contents" tool). - **Also:** `path: ""` fails with `gitea_repo_contents failed: invalid owner, repo, or filePath`, so directories cannot be listed either. - **Workaround:** clone the repo, or `GET /api/v1/repos/{owner}/{repo}/contents/{path}` with `GITEA_TOKEN`. ## 3. `gitea_issue_list` silently truncates when `limit > 20` On `pvlb-infra/vps-setup` (28 issues, `state=all`): | call | result | |---|---| | `limit: 5, page: 1` | 5 rows (fine) | | `limit: 100, page: 1` | 20 rows | | `limit: 50, page: 1` | 20 rows | | `limit: 50, page: 2` | `OK` (empty) — but issues #9–#2 remain | | `limit: 20, page: 2` | 8 rows (fine) | Looks like the page size is clamped to 20 but the offset is still `(page - 1) * limit`, so page 2+ is skipped silently. A naive "list everything" call misses 8 of 28 issues in a single repo — exactly the failure mode a cross-project digest cannot afford. - **Workaround:** always pass `limit <= 20`, then page through. ## 4. Empty results render as a bare `OK` - **Repro:** `gitea_issue_list` on `pvlb-infra/issue-tracker` or `pvlb-infra/forge-runner` (0 issues) → `OK`. Same for `gitea_labels list` on a repo without labels, and `gitea_labels create` on success. - **Expected:** `[]`, "no issues", or the created object — right now "empty" and "it worked" are indistinguishable without a second query. ## Verified *not* broken - `owner`/`repo`/`state` filtering is correct (`t14-deeps` open → 5 rows; `dsh-resend-mcp` all → 7 rows). - Issue numbers are repo-scoped, as expected. ## Acceptance - [ ] `gitea_wiki get` returns the page body. - [ ] `gitea_repo_contents` returns file content (and either supports directory listing or says so in its description). - [ ] `gitea_issue_list` honours `limit` up to the server max *and* paginates consistently. - [ ] Empty result sets are explicit, not `OK`.

dsh added the

type/bug

area/forgejo

priority/next

labels

2026-10-23 17:02:14 +00:00

dsh changed title from ~~Tool bugs seen from issue-tracker work (2026-10-23): wiki get, repo contents, issue pagination, empty responses~~ to Tool bugs seen from issue-tracker work (2026-10-23): wiki get, repo contents, issue pagination, empty responses, label assignment

2026-10-23 17:03:10 +00:00

dsh commented

2026-10-23 17:03:11 +00:00

Author

Owner

5. `gitea_issue_create` ignores `labels` (names), silently

Found immediately after filing the first two issues.

Repro: created this issue with labels: ["type/bug", "area/forgejo", "priority/next"]; it opened with zero labels. Same for the companion issue in pvlb-infra/issue-tracker.
Expected: labels attached, or an error naming the unknown label.
Workaround: create the issue, read the repo label ids (GET /api/v1/repos/{owner}/{repo}/labels), then gitea_labels {action: "set", number, labels: [<ids>]}. Numeric ids work; names do not.
Why it is surprising: the parameter is typed as a list of strings, which reads as "names are supported". A silent no-op means the caller believes the issue is triaged when it is not.

Combined with #4 (empty/OK responses), the failure mode is nasty: create + set both answer OK, and only a third read shows the labels never landed.

## 5. `gitea_issue_create` ignores `labels` (names), silently Found immediately after filing the first two issues. - **Repro:** created this issue with `labels: ["type/bug", "area/forgejo", "priority/next"]`; it opened with **zero labels**. Same for the companion issue in `pvlb-infra/issue-tracker`. - **Expected:** labels attached, or an error naming the unknown label. - **Workaround:** create the issue, read the repo label ids (`GET /api/v1/repos/{owner}/{repo}/labels`), then `gitea_labels {action: "set", number, labels: [<ids>]}`. Numeric ids work; names do not. - **Why it is surprising:** the parameter is typed as a list of strings, which reads as "names are supported". A silent no-op means the caller believes the issue is triaged when it is not. Combined with #4 (empty/`OK` responses), the failure mode is nasty: create + set both answer `OK`, and only a third read shows the labels never landed.

dsh commented

2026-10-23 17:18:08 +00:00

Author

Owner

Split into one actionable issue per defect, each with root cause (file:line) and a concrete fix:

#2 — gitea_issue_list silently hides everything past 20 rows (formatters.js:205) — priority/now
#3 — gitea_repo_contents returns the path, not the file body (formatters.js:230)
#4 — gitea_wiki get answers OK; the REST endpoint is metadata-only
#5 — empty/unrecognised results render as bare OK (formatters.js:211 and :287)
#6 — gitea_issue_create cannot set labels/assignee/milestone (issues.js:104)

Closing this tracker. New tool bugs get their own issue from now on (one defect = one issue), and pvlb-infra/issue-tracker/AGENTS.md keeps the live table with links.

Split into one actionable issue per defect, each with root cause (file:line) and a concrete fix: - #2 — `gitea_issue_list` silently hides everything past 20 rows (`formatters.js:205`) — **priority/now** - #3 — `gitea_repo_contents` returns the path, not the file body (`formatters.js:230`) - #4 — `gitea_wiki get` answers `OK`; the REST endpoint is metadata-only - #5 — empty/unrecognised results render as bare `OK` (`formatters.js:211` and `:287`) - #6 — `gitea_issue_create` cannot set labels/assignee/milestone (`issues.js:104`) Closing this tracker. New tool bugs get their own issue from now on (one defect = one issue), and `pvlb-infra/issue-tracker/AGENTS.md` keeps the live table with links.

dsh closed this issue

2026-10-23 17:18:10 +00:00

dsh referenced this issue

2026-10-23 22:54:50 +00:00

feat(issues): gitea_issue_create cannot set labels, assignee or milestone #6