dsh-plugins/dsh-gitea

Watch

Fork 0

fix(tools): empty and unrecognised results render as a bare OK #5

New issue

Closed

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

dsh commented

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

Owner

Symptom

A bare OK is returned for wildly different outcomes, so the caller cannot tell "nothing there" from "done" from "unrecognised response":

gitea_issue_list on a repo with 0 issues (pvlb-infra/issue-tracker, pvlb-infra/forge-runner)
gitea_labels list on a repo with no labels
gitea_labels create on success
gitea_wiki get (a real object — see #4)
any JSON object the formatter does not recognise

This is not cosmetic: while bootstrapping issue-tracker it hid #2 and #4 until the REST API was checked by hand, and it twice made a failed label assignment look successful.

Root cause

// lib/handlers/formatters.js:211
return [{ type: 'text', text: lines.join('\n') || 'OK' }]
// lib/handlers/formatters.js:287 (end of function)
return [{ type: 'text', text: 'OK' }]

Plus wrap() intentionally returns {ok:true} with no data when an endpoint answers with an empty body (lib/handlers/common.js:175), which is correct — the formatter then has nothing to say.

Fix

Never emit a bare OK:

empty array → No issues. / No labels. / No results. (per tool)
unknown object → one line of identifying fields (title, name, number) or a short JSON snippet
successful write → echo the created/updated object (Label "type/bug" created (id 13), Milestone "v1" created (id 4))
genuinely empty response ({ok:true} with no data) → Done. — distinct from OK, at least.

Acceptance

grep -n "'OK'" lib/handlers/formatters.js finds no bare fallback.
every tool listed above returns a specific message.

## Symptom A bare `OK` is returned for wildly different outcomes, so the caller cannot tell "nothing there" from "done" from "unrecognised response": - `gitea_issue_list` on a repo with 0 issues (`pvlb-infra/issue-tracker`, `pvlb-infra/forge-runner`) - `gitea_labels list` on a repo with no labels - `gitea_labels create` on success - `gitea_wiki get` (a real object — see #4) - any JSON object the formatter does not recognise This is not cosmetic: while bootstrapping `issue-tracker` it hid #2 and #4 until the REST API was checked by hand, and it twice made a failed label assignment look successful. ## Root cause ```js // lib/handlers/formatters.js:211 return [{ type: 'text', text: lines.join('\n') || 'OK' }] // lib/handlers/formatters.js:287 (end of function) return [{ type: 'text', text: 'OK' }] ``` Plus `wrap()` intentionally returns `{ok:true}` with **no** data when an endpoint answers with an empty body (`lib/handlers/common.js:175`), which is correct — the formatter then has nothing to say. ## Fix Never emit a bare `OK`: - empty array → `No issues.` / `No labels.` / `No results.` (per tool) - unknown object → one line of identifying fields (`title`, `name`, `number`) or a short JSON snippet - successful write → echo the created/updated object (`Label "type/bug" created (id 13)`, `Milestone "v1" created (id 4)`) - genuinely empty response (`{ok:true}` with no data) → `Done.` — distinct from `OK`, at least. ## Acceptance - [ ] `grep -n "'OK'" lib/handlers/formatters.js` finds no bare fallback. - [ ] every tool listed above returns a specific message.

dsh added the

type/bug

area/forgejo

priority/next

labels

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

dsh referenced this issue

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

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

dsh referenced this issue

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

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

dsh referenced this issue

2026-10-23 17:44:28 +00:00

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

dsh commented

2026-10-23 17:44:32 +00:00

Author

Owner

Additional data point from t14btw (2026-10-23), same bare-OK fallback on non-empty results — so it is not limited to empty lists:

gitea_flavor → OK (no flavor/version payload at all, although /api/v1/version answers 17.0.0+gitea-1.22.0). A populated single-object tool definitely deserves its own formatter.
Empty gitea_labels list and gitea_notifications also render OK, which is ambiguous with the flavor case above.
gitea_wiki get has the same problem and is tracked separately as #4.

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

Additional data point from `t14btw` (2026-10-23), same bare-`OK` fallback on **non-empty** results — so it is not limited to empty lists: * `gitea_flavor` → `OK` (no flavor/version payload at all, although `/api/v1/version` answers `17.0.0+gitea-1.22.0`). A populated single-object tool definitely deserves its own formatter. * Empty `gitea_labels` list and `gitea_notifications` also render `OK`, which is ambiguous with the flavor case above. * `gitea_wiki get` has the same problem and is tracked separately as #4. Environment: DSH `0.2.0-rc.2`, `dsh-gitea` `0.7.40-dsh.1` (link: checkout), Forgejo `17.0.0+gitea-1.22.0`.

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:33 +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).

Every OK fallback is gone (grep -n "'OK'" lib/handlers/formatters.js → none).
Empty arrays return a per-tool message (No issues., No labels., No pull requests., …, fallback No results.); unknown objects print identifying fields plus a ≤300-char JSON snippet; {ok:true} with no payload returns Done.
Live check: gitea_pr_list on this repo now answers No pull requests. instead of a bare OK.

Fixed in 4d77e9f (`fix(tools): render complete lists and never print a bare OK`), merged to `master` (#11). - Every `OK` fallback is gone (`grep -n "'OK'" lib/handlers/formatters.js` → none). - Empty arrays return a per-tool message (`No issues.`, `No labels.`, `No pull requests.`, …, fallback `No results.`); unknown objects print identifying fields plus a ≤300-char JSON snippet; `{ok:true}` with no payload returns `Done.` - Live check: `gitea_pr_list` on this repo now answers `No pull requests.` instead of a bare `OK`.

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

dsh referenced this issue

2026-10-23 22:37:56 +00:00

fix(wiki): render wiki page metadata instead of a bare identifier #14

dsh referenced this issue

2026-10-23 22:38:07 +00:00

fix(wiki): gitea_wiki get answers OK and can never return page content #4

dsh referenced this issue

2026-10-24 00:59:04 +00:00

fix(dedupe): gitea_issue_duplicates misses an exact-title duplicate when the existing body is long #30