Find a workflow run past the first page of the run list #290

Merged

stephen merged 5 commits from fix/run-lookup-past-first-page into main

2026-10-13 03:59:18 +00:00

stephen commented

2026-10-13 02:46:34 +00:00

Owner

Every run command turns a run number into the internal id by reading the run list, and that read stopped after 50 runs. Forgejo sends no Link header on actions/runs, only total_count, so the pagination that followed the header never left page one. In a busy repository any run older than the newest 50 came back as "workflow run #N was not found". That is the unexplained half of #248: rasterstate/paragon has over 10,000 runs, and fj run view 5400 --log-failed could not see past the last few hours.

The lookup now asks the server for the run number (run_number=N), which is one request however old the run is. A server that ignores the filter answers with its newest page, and in that case fj walks the list as before. The walk itself follows total_count when there is no Link header, so fj run list --paginate returns more than one page as well. A page that adds no new run ends the walk whatever the total says, so an overstated count cannot spin it.

Checked against paragon with a build of this branch: runs 10453, 10095 and 5400 all return their failed logs, and all three were "not found" on v0.6.0. Run 5399, the other example in the issue, is a green run by run number (the id in the issue came from a different namespace), so the empty result was right. It now reads "Run #5399 has no failed jobs" instead of "No matching jobs in this run".

One cost to know about: a server that ignores the filter has its first page fetched twice, once by the probe and once by the walk.

The lockfile commit is the same quinn-proto bump as #288, carried here so the audit gate passes on its own.

Closes #248

Every run command turns a run number into the internal id by reading the run list, and that read stopped after 50 runs. Forgejo sends no `Link` header on `actions/runs`, only `total_count`, so the pagination that followed the header never left page one. In a busy repository any run older than the newest 50 came back as "workflow run #N was not found". That is the unexplained half of #248: `rasterstate/paragon` has over 10,000 runs, and `fj run view 5400 --log-failed` could not see past the last few hours. The lookup now asks the server for the run number (`run_number=N`), which is one request however old the run is. A server that ignores the filter answers with its newest page, and in that case fj walks the list as before. The walk itself follows `total_count` when there is no `Link` header, so `fj run list --paginate` returns more than one page as well. A page that adds no new run ends the walk whatever the total says, so an overstated count cannot spin it. Checked against paragon with a build of this branch: runs 10453, 10095 and 5400 all return their failed logs, and all three were "not found" on v0.6.0. Run 5399, the other example in the issue, is a green run by run number (the id in the issue came from a different namespace), so the empty result was right. It now reads "Run #5399 has no failed jobs" instead of "No matching jobs in this run". One cost to know about: a server that ignores the filter has its first page fetched twice, once by the probe and once by the walk. The lockfile commit is the same quinn-proto bump as #288, carried here so the audit gate passes on its own. Closes #248

stephen added 3 commits

2026-10-13 02:46:34 +00:00

Find a workflow run past the first page of the run list f96b408b58

Every run command resolves a run number to the internal id by reading
the run list, and that read stopped after 50 runs: Forgejo sends no Link
header on actions/runs, so the pagination that followed it never left
page one. In a busy repository any run older than the newest 50 was
reported as not found, which is the second half of #248.

The lookup now asks the server for the run number directly, one request
however old the run is. A server that ignores the filter still gets the
full walk, and the walk follows total_count when there is no Link
header, so fj run list --paginate also returns more than one page. A
page that adds nothing new ends the walk regardless of the total.

fj run view --log-failed on a run with no failed jobs now says so
instead of "No matching jobs in this run".

Note the run lookup fix in the changelog 7994650fe6

Update quinn-proto past five RustSec advisories

ci / coverage (pull_request) Has been cancelled

Details

ci / live-e2e (pull_request) Has been cancelled

Details

ci / check (pull_request) Has been cancelled

Details

814d53fb53

RUSTSEC-2026-0338 through 0342 landed against quinn-proto 0.11.15 and fail
the audit gate. The lockfile moves to a fixed release; nothing in fj's own
manifest changes.

(cherry picked from commit 4aa845981e)

stephen added 1 commit

2026-10-13 02:59:13 +00:00

Merge remote-tracking branch 'origin/main' into fix/run-lookup-past-first-page

ci / check (pull_request) Successful in 24m25s

Details

ci / coverage (pull_request) Successful in 4m7s

Details

ci / live-e2e (pull_request) Successful in 5m19s

Details

201faea931