fix(api): non-2xx responses are errors on both surfaces - jq/template never runs on an error body #181
No reviewers
Labels
No labels
breaking
bug
documentation
enhancement
epic
good first issue
help wanted
refactoring
resolution/duplicate
resolution/invalid
resolution/wontfix
security
severity/critical
severity/high
severity/low
severity/medium
status/abandoned
status/blocked
status/needs-decision
status/needs-info
status/needs-verification
testing
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sixfold-space/madtea!181
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "refs/pull/181/head"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
madt_api_callreturned non-2xx responses as ordinary data: no isError, no status code anywhere, and a jq/template filter would happily transmute an error envelope into plausible-looking results (a live Codeberg 500 masqueraded as a search-result count of 2 and derailed an outage diagnosis for an hour - #153).The >=400 check now lives in the shared service Call() itself, before any jq/template transform, returning
API error <code>: <body>- the same shape as the typed client path. MCP gets a proper tool error; the CLI's now-dead post-hoc status block is removed, somadtea apikeeps its gh-style non-zero exit with the unified message. No opt-out/status-probing parameter in this pass (deferred; no in-repo caller needs it - gh api is fail-loud too).Tests pin the jq-on-error-body shape specifically on both the service and MCP surfaces; COMPARISON api row updated.
Closes #153.
Closes #153