Repository navigation
fix(pr-management-triage): post-filter on conclusion to find action_required runs - #112
Merged
Merged
Conversation
…equired runs The `?status=action_required` query parameter on the Actions runs REST endpoint does not match runs awaiting maintainer approval. GitHub returns those runs as `status: "completed"` with `conclusion: "action_required"`, so `?status=action_required` silently returns an empty result. Replace the broken filter in all four places it was used (`fetch-and-batch.md` mandatory index + three recipes in `actions.md`) with `?per_page=N` and a jq post-filter on `conclusion`. Add explanatory text in fetch-and-batch.md and inline comments in the recipes so a future reader does not reintroduce the broken filter. The `gh api -X POST .../approve` mutation itself works fine against runs in this state — only the discovery queries were broken.
Member
Author
|
Found during testing with steward adopted in Airflow :) |
4 of 5 tasks
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.
Summary
The
?status=action_requiredquery parameter onGET /repos/{owner}/{repo}/actions/runsdoes not return runs awaiting maintainer approval. GitHub returns those runs asstatus: "completed"withconclusion: "action_required"(the queueing phase is finished, but the run is blocked pending approval).The triage skill used
?status=action_requiredin 4 places — none of them returned anything, which letpending_workflow_approvalPRs slip through classification aspassingand would have caused themark-readyguard to silently fail-open.Empirical evidence
Hit live during a triage sweep on
apache/airflowtoday: the mandatoryaction_requiredREST index missed 13 pending workflow runs across 4 first-time-contributor PRs (caught by the rollup-pattern Real-CI guard, but only because all 4 had no real CI in the rollup). One of the twomark-ready-classified PRs (#65974) had 3 pending workflow runs at its head SHA — the broken pre-check would have label-added it as ready for review.Changes
Replace
?status=action_requiredwith?per_page=N+ jq post-filterselect(.conclusion == "action_required")in 4 places:fetch-and-batch.md— mandatory per-page REST indexactions.md—mark-readypre-mutation guardactions.md—mark-ready-with-pingpre-mutation guardactions.md—approve-workflowrecipe (used to discover the run IDs to approve)Add explanatory text in
fetch-and-batch.mdand inline comments in the recipes so a future reader doesn't reintroduce the broken filter.The
gh api -X POST .../approvemutation itself works against runs in this state (verified: 16 successful approvals during the same triage sweep) — only the discovery query was broken.Test plan
prek run --filespasses (markdownlint, skill-validate, etc.)apache/airflow(16 runs across 5 PRs)Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 4.7) following the guidelines