fix(wiki): gitea_wiki list fails with "The target couldn't be found" on an empty wiki #9

Closed
opened 2026-10-23 17:44:28 +00:00 by dsh · 1 comment
Owner

Symptom

gitea_wiki with action: "list" fails on a repository whose wiki is enabled but empty.

Verbatim tool output (t14btw, 2026-10-23):

gitea_wiki failed: The target couldn't be found.

Repro

  1. Pick a repo with the wiki unit enabled and no pages yet — e.g. ml-lab/tardits (has_wiki: true, zero pages).
  2. Call gitea_wiki {action: "list", owner: "ml-lab", repo: "tardits"} → error above.
  3. The underlying API, verbatim:
GET /api/v1/repos/ml-lab/tardits/wiki/pages -> 404
{"message":"The target couldn't be found.","url":"https://git.pvlb.dev/api/swagger","errors":["no such file or directory"]}

Environment: DSH 0.2.0-rc.2, dsh-gitea 0.7.40-dsh.1 (776e0f5, link: checkout), Forgejo 17.0.0+gitea-1.22.0.

Observed vs expected

  • Observed: a hard tool error, indistinguishable from a missing repo, a disabled wiki, or an API outage.
  • Expected: success with an empty page list (or an explicit "no wiki pages" result).

Root cause (checkout available)

  • lib/gitea-client.js:609-613 — listWikiPages() returns this.request('GET', …/wiki/pages) directly; no 404 handling.
  • lib/gitea-client.js:210-216 — non-ok responses become {ok:false, error: data?.message …}; Forgejo's 404 message is surfaced verbatim as the tool error.
  • lib/handlers/repos.js:133-141 — case 'gitea_wiki' passes that through wrap() (lib/handlers/common.js:166).
  • Pattern already in-tree to mirror: lib/gitea-client.js:467-474 (getPullMergeStatus, #296) maps 404 to a successful, meaningful result.

Proposed fix

In listWikiPages() (or in the gitea_wiki list branch), map status === 404 to {ok: true, status: 404, data: []}. Optionally consult the repo's has_wiki to word "no pages yet" vs "wiki disabled", and keep the raw 404 body out of the tool error path.

Acceptance

  • Unit test with a mocked fetch 404: gitea_wiki list resolves ok: true with an empty list and no error text.
  • Live: gitea_wiki {action:"list", owner:"ml-lab", repo:"tardits"} returns an empty success.
  • Live: pvlb-infra/t14-deeps (has pages) still lists all pages.
  • 401/403/5xx keep failing as before — no blanket swallowing.

Duplicate check

Searched open + closed before filing: #4 (get returns only OK) and #5 (bare OK for empty/unrecognised results) are related but distinct — this is the list 404 path only, first reported here.

Layer

Plugin/tool bug → dsh-gitea (correct repo).

## Symptom `gitea_wiki` with `action: "list"` fails on a repository whose wiki is **enabled but empty**. Verbatim tool output (t14btw, 2026-10-23): ``` gitea_wiki failed: The target couldn't be found. ``` ## Repro 1. Pick a repo with the wiki unit enabled and no pages yet — e.g. `ml-lab/tardits` (`has_wiki: true`, zero pages). 2. Call `gitea_wiki {action: "list", owner: "ml-lab", repo: "tardits"}` → error above. 3. The underlying API, verbatim: ``` GET /api/v1/repos/ml-lab/tardits/wiki/pages -> 404 {"message":"The target couldn't be found.","url":"https://git.pvlb.dev/api/swagger","errors":["no such file or directory"]} ``` Environment: DSH `0.2.0-rc.2`, `dsh-gitea` `0.7.40-dsh.1` (`776e0f5`, link: checkout), Forgejo `17.0.0+gitea-1.22.0`. ## Observed vs expected - **Observed:** a hard tool error, indistinguishable from a missing repo, a disabled wiki, or an API outage. - **Expected:** success with an empty page list (or an explicit "no wiki pages" result). ## Root cause (checkout available) - `lib/gitea-client.js:609-613` — `listWikiPages()` returns `this.request('GET', …/wiki/pages)` directly; no 404 handling. - `lib/gitea-client.js:210-216` — non-ok responses become `{ok:false, error: data?.message …}`; Forgejo's 404 `message` is surfaced verbatim as the tool error. - `lib/handlers/repos.js:133-141` — `case 'gitea_wiki'` passes that through `wrap()` (`lib/handlers/common.js:166`). - Pattern already in-tree to mirror: `lib/gitea-client.js:467-474` (`getPullMergeStatus`, #296) maps 404 to a successful, meaningful result. ## Proposed fix In `listWikiPages()` (or in the `gitea_wiki` list branch), map `status === 404` to `{ok: true, status: 404, data: []}`. Optionally consult the repo's `has_wiki` to word "no pages yet" vs "wiki disabled", and keep the raw 404 body out of the tool error path. ## Acceptance - [ ] Unit test with a mocked `fetch` 404: `gitea_wiki list` resolves `ok: true` with an empty list and no error text. - [ ] Live: `gitea_wiki {action:"list", owner:"ml-lab", repo:"tardits"}` returns an empty success. - [ ] Live: `pvlb-infra/t14-deeps` (has pages) still lists all pages. - [ ] 401/403/5xx keep failing as before — no blanket swallowing. ## Duplicate check Searched open + closed before filing: #4 (`get` returns only `OK`) and #5 (bare `OK` for empty/unrecognised results) are related but distinct — this is the `list` 404 path only, first reported here. ## Layer Plugin/tool bug → `dsh-gitea` (correct repo).
dsh closed this issue 2026-10-23 22:36:55 +00:00
Author
Owner

Fixed in 913013a (PR #13).

listWikiPages() now maps the empty-wiki 404 from GET /wiki/pages to { ok: true, status: 404, data: [] }; 401/403/5xx still fail. Covered by test/wiki.test.mjs.

Live check through the running plugin:

  • gitea_wiki {action:"list", owner:"ml-lab", repo:"tardits"} → No wiki pages.
  • gitea_wiki {action:"list", owner:"pvlb-infra", repo:"t14-deeps"} → all 3 pages listed.
Fixed in `913013a` (PR #13). `listWikiPages()` now maps the empty-wiki `404` from `GET /wiki/pages` to `{ ok: true, status: 404, data: [] }`; 401/403/5xx still fail. Covered by `test/wiki.test.mjs`. Live check through the running plugin: - `gitea_wiki {action:"list", owner:"ml-lab", repo:"tardits"}` → `No wiki pages.` - `gitea_wiki {action:"list", owner:"pvlb-infra", repo:"t14-deeps"}` → all 3 pages listed.
Sign in to join this conversation.
No milestone
No project
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
dsh-plugins/dsh-gitea#9
No description provided.