fix(pr-management-triage): filter action_required runs server-side - #1088
Open
potiuk wants to merge 1 commit into
Open
fix(pr-management-triage): filter action_required runs server-side#1088potiuk wants to merge 1 commit into
potiuk wants to merge 1 commit into
Conversation
The repo-wide pending-approval index is documented as an unfiltered `event=pull_request` listing, post-filtered on `conclusion` and capped at the first three pages, on the stated grounds that `?status=action_required` "matches no runs in this state". That premise is wrong — the parameter does match, and SKILL.md Golden rule 1b already depends on it, so the two files contradict each other. The consequence is a silent under-report rather than an error. The listing is newest-first across all states, so on a busy repository three pages reach back only a few hours while the approval backlog is unbounded. A sweep on a large adopter repo saw 9 of 322 pending head SHAs; every PR in the gap whose rollup was green from bot checks alone classified as passing and became a mark-ready candidate, which is the exact false-positive the index exists to prevent. The per-PR lookups in actions.md are scoped to a single head SHA and were never affected by the truncation, so their code is left alone and only the inaccurate rationale is corrected. Generated-by: Claude Code (Opus 5)
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.
fetch-and-batch.mdbuilds the repo-wideaction_requiredindex from anunfiltered
event=pull_requestlisting, post-filtered onconclusionandcapped at the first three pages, justified by the claim that
?status=action_required"matches no runs in this state and silently returnsan empty result".
The claim is incorrect, and the framework already contradicts itself —
SKILL.mdGolden rule 1b uses?status=action_required&head_sha=<SHA>.Measured impact
Full triage sweep against a large adopter repo (2026-08):
?status=action_required, paginatedevent=pull_requestpost-filter?status=action_requiredreported 1109 matching runs. The 3-page windowreached back only ~12 hours, because that repo produces ~300
pull_requestruns in that time. Every PR in the ~313-SHA gap whose rollup was green from bot
checks alone (
Mergeable,WIP,DCO) classified aspassingand became amark-readycandidate — the precise false-positive class this index exists toprevent, and the one Golden rule 1b is written to stop.
Changes
fetch-and-batch.md: filter server-side, walk every page, and note the1000-result listing cap with the
created:-window workaround. The incorrectrationale is replaced with the measured one.
actions.md: the two per-PR lookups are scoped to a single head SHA and werenever affected by the truncation. Their code is unchanged; only the
inaccurate claim in the comments is corrected, with a pointer to why the
repo-wide case differs.
A
conclusionpost-filter over the filtered set is kept as belt-and-braces,and stays correct for a host whose API build ignores
status.Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 5)