api: exit nonzero on HTTP error responses (gh api parity) #105

New issue

Closed

opened 2026-07-15 16:11:23 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-15 16:11:23 +00:00

(Migrated from codeberg.org)

madtea api exits 0 on HTTP error responses, printing the error JSON to stdout:

$ madtea api "/repos/sixfold_space/madtea/releases/tags/vX.Y.Z-nonexistent"; echo $?
{"message":"The target couldn't be found.","url":"https://codeberg.org/api/swagger","errors":[]}
0

gh api exits 1 on any non-2xx response (and prints the error to stderr), so scripts can use it in if/&& chains. madtea's behavior makes exit-code checks against madtea api always-true, which is a silent trap.

Real-world impact: scripts/release.sh's forge_release_exists() checked madtea api .../releases/tags/$tag's exit code — always true, so the v0.15.1 release run skipped goreleaser for a release that didn't exist, stranding a pushed tag with no forge release (fixed script-side in #104 by switching to madtea release get, which exits nonzero correctly). scripts/check-satellite-readiness.sh:45 carries the same wrong assumption in its comment ("A missing/unreachable repo makes the GET fail (non-zero)" — it doesn't); it only fails safe by accident, via the *) case on the unparseable --jq output.

Acceptance criteria:

madtea api (CLI) and madt_api_call exit/error consistently: non-2xx → nonzero exit (CLI) with the error on stderr, matching gh api.
The MCP tool already errors on non-2xx (returns "API error 404: ..."); confirm parity is CLI-side only.
scripts/check-satellite-readiness.sh's unreachable-repo branch works as its comment describes once the exit code is honest.
docs/COMPARISON.md row for api updated if behavior was documented as differing.

`madtea api` exits 0 on HTTP error responses, printing the error JSON to stdout: ``` $ madtea api "/repos/sixfold_space/madtea/releases/tags/vX.Y.Z-nonexistent"; echo $? {"message":"The target couldn't be found.","url":"https://codeberg.org/api/swagger","errors":[]} 0 ``` `gh api` exits 1 on any non-2xx response (and prints the error to stderr), so scripts can use it in `if`/`&&` chains. madtea's behavior makes exit-code checks against `madtea api` always-true, which is a silent trap. **Real-world impact:** `scripts/release.sh`'s `forge_release_exists()` checked `madtea api .../releases/tags/$tag`'s exit code — always true, so the v0.15.1 release run skipped goreleaser for a release that didn't exist, stranding a pushed tag with no forge release (fixed script-side in #104 by switching to `madtea release get`, which exits nonzero correctly). `scripts/check-satellite-readiness.sh:45` carries the same wrong assumption in its comment ("A missing/unreachable repo makes the GET fail (non-zero)" — it doesn't); it only fails safe by accident, via the `*)` case on the unparseable `--jq` output. **Acceptance criteria:** - `madtea api` (CLI) and `madt_api_call` exit/error consistently: non-2xx → nonzero exit (CLI) with the error on stderr, matching `gh api`. - The MCP tool already errors on non-2xx (returns "API error 404: ..."); confirm parity is CLI-side only. - `scripts/check-satellite-readiness.sh`'s unreachable-repo branch works as its comment describes once the exit code is honest. - `docs/COMPARISON.md` row for `api` updated if behavior was documented as differing.

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

sixfold-space/madtea#105

No description provided.

Rows
Columns