Ask per workflow for whatever the runs feed missed - #3
Merged
Conversation
The runs feed is ordered by created_at and is not a per-workflow view, so on a busy repo it is dominated by whatever runs most often. cvxgrp/simulator has 2406 completed runs on main; the first hundred cover only 6 of its 23 active workflows. Every other workflow is invisible, and a quiet one that is failing stays invisible indefinitely. That is how the board reported 0 red while simulator's (RHIZA) WEEKLY had failed three times running over 40 days. Fixing it also surfaced Jebel-Quant/jquantstats "Autopilot", red for 156 days on its only ever run and never once reported. Anything the feed does not account for is now requested directly, one call per missing workflow. Quiet repos pay nothing; only busy ones do, and only for what was actually hidden. Workflows with no completed run on the default branch are correctly absent rather than assumed green - simulator has four such. Measured after the change: 207 workflows tracked, up from 175; 80 calls per refresh, about 960/hour against the 5000 budget; refresh 14s -> 26s. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Aug 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
/actions/runsis ordered bycreated_atand is not a per-workflow view, so on a busy repo it is dominated by whatever runs most often.cvxgrp/simulatorhas 2406 completed runs on main; the first hundred cover only 6 of its 23 active workflows. Everything else is invisible — and a quiet workflow that is failing stays invisible indefinitely.That is how the board reported 0 red while
simulator's(RHIZA) WEEKLYhad failed three times running over 40 days.Fixing it also surfaced a failure that had never once been reported:
Jebel-Quant/jquantstats/Autopilot, red for 156 days on its only ever run.The change
Anything the feed does not account for is now requested directly, one call per missing workflow. Quiet repos pay nothing extra; only busy ones do, and only for what was actually hidden.
Workflows with no completed run on the default branch stay correctly absent rather than being assumed green —
simulatorhas four of those ((RHIZA) RELEASE, the three Copilot agents), which is why it reports 19 workflows rather than 23.Why the feed alone was never going to work
This is the third bug in the same family, and the root cause each time was treating run history as an authority it is not:
per_page=1→ only ever saw one workflow per repo/actions/workflowsis the authority for which workflows exist and what they are called; the runs feed is only a fast path for their recent state. This change makes that split complete.Measured
simulatorworkflows visibleVerified from a clean
git archiveof the branch against live GitHub.🤖 Generated with Claude Code