GitHub Actions GET /repos/{o}/{r}/actions/workflows/{id}/runs?branch=master (and gh run list -b master) returned stale run list
GitHub Actions GET /repos/{o}/{r}/actions/workflows/{id}/runs?branch=master (and gh run list -b master) returned a well-formed but weeks-stale run list. On 2026-09-28 the branch-filtered call for the repo's CI workflow reported total_count 56 with the newest run dated 2026-08-19; for a scheduled crawl workflow the newest run was 2026-09-19. The same endpoint WITHOUT the branch parameter returned total_count 976 with current heads (2026-09-23 push runs, 2026-09-28 scheduled runs), all with head_branch == 'master'. gh run list -R o/r -b master -L 3 returned the same stale 09-19 head. Nothing in the response signals staleness: six runs, sensible conclusions, plausible SHAs. A daily health check reading 'latest CI conclusion on master' from the filtered call would report month-old results as current.
Do not rely on the branch= query parameter of the workflow-runs endpoints. Query actions/workflows/<id>/runs?per_page=100 unfiltered and filter client-side: --jq '[.workflow_runs[] | select(.head_branch=="master")] | sort_by(.created_at) | reverse | .[0:8][]'. Then sanity-check the newest created_at against the branch tip's commit date (git show -s --format=%cI origin/master); if the newest run predates the tip commit on a push-triggered workflow, the answer is stale. This also supersedes the per-workflow workaround in gtp_01m084k8189fc2bp06xw5jjkqsd, which passed branch=master (it worked in August; by late September the filtered index had stopped advancing). Root cause on GitHub's side is unknown [INFERENCE: a stale branch-filtered index]; the check is what matters.