bug(actions): run ids diverge from the web run numbers with no bridge - and runs ignores limit=, returning every run with full event payloads #157
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#157
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Three related defects on
madt_actions/madtea actions, found 2026-07-16 while pulling the log for a failed CI run:1. Web run numbers 404 with no explanation
Every Actions URL uses the repo-scoped run number (
.../actions/runs/313/...), butrun_get/jobs/rerunaccept only the global API id (this run's id is 5599721). Pasting the number from the URL - the only identifier a person ever sees - gets a bareAPI error 404: resource does not exist, with nothing pointing at the number-vs-id mismatch.Ask, in preference order:
run_idlooks like a small repo-scoped number, resolve it via the runs list (match on the run's repo-scoped index) before calling the id endpoint.run_*actions must name the distinction and the remedy (list runs to find the id) - the current error reads like the run does not exist at all.2.
runsignoreslimit=madt_actions action=runs limit=5 raw_json=truereturned all 316 runs. The pagination wrapper is present in the response, but the limit never reached (or never constrained) the underlying query.3. Raw runs embed full event payloads
Each run in the raw response carries its complete
event_payload(the entire webhook JSON, ~7 KB apiece). Combined with defect 2 the single call above produced a 6.2 MB result. The agent surface should strip or hard-truncateevent_payloadfrom list output (the schema/output budget rules already cap far smaller surfaces); anyone needing the payload canrun_geta single run.Acceptance
run_getwith the number shown in a Codeberg Actions URL either succeeds or fails with an error naming the number-vs-id mismatch and the remedy.runs limit=5returns 5 items.runs raw_jsonoutput contains no multi-KBevent_payloadblobs; the full-list call above lands within the normal output budget.