Summary
The pr-review agent correctly skips PRs whose CI is failing or in-progress (decision: skip, reason: ci-pending | ci-failing). These skips are designed to be re-evaluated by a later check_suite:completed event. But when CI settles green after the last review trigger fires — common on PRs where dev-lead is actively pushing fixes / re-running CI — no trigger re-fires, and the PR sits at REVIEW_REQUIRED with green CI, never re-reviewed.
The result is a growing backlog of PRs that look like "pr-review is down" but are actually just never re-triggered after their CI went green.
Evidence (2026-06-11)
PRs with fully green CI (zero IN_PROGRESS/QUEUED items in statusCheckRollup) but no bot review and reviewDecision = REVIEW_REQUIRED:
| PR |
CI now |
Bot review? |
| #569 |
all green |
none |
| #518 |
all green |
none |
| #550 |
all green |
none |
| #549 |
all green |
none |
Trigger timeline for #569 (head 7d608fee):
- 16:36 — last
check_suite-triggered review run → {"pr":".../569","decision":"skip","reason":"ci-pending"} ("CI checks still in progress") — legitimate at the time (dev-lead still pushing).
- ~16:38 — CI suites finished green (last github-actions suite
success at 16:38:15).
- After 16:38 — no further
check_suite-triggered review run until an unrelated 17:36 run (skipped). The green state never produced a fresh review.
The engine itself is healthy — every triggered run initializes the cascade fine (engine: claude (triage: haiku 4.5 → deep: sonnet 4.6 + duck: o4-mini → audit: opus 4.7), auth OK, review decision: REVIEW_REQUIRED reached). This is purely a re-trigger gap, not an engine/auth/CLI failure.
Why the safety net doesn't catch it
daily-pr-review-health.yml is a reporter (opens issues about failed runs); it does not re-review stuck-green PRs, so it can't rescue this backlog.
Proposed fix
Add a re-review path for PRs that were skipped ci-pending/ci-failing and have since gone green. Options:
- A scheduled sweep (cron) that enumerates open
REVIEW_REQUIRED PRs whose CI is now green and re-dispatches a review (reuse list-prs.sh / review-batch.sh).
- Or extend
daily-pr-review-health.yml from reporter → remediator for this specific case.
- Tighten the event-driven path so a final green
check_suite:completed reliably re-triggers (the current path races against in-flight CI / dev-lead pushes).
Immediate workaround
Manually dispatch pr-review-trigger.yml with no pr_url (batch mode) to clear the current green backlog (#569, #518, #550, #549).
Related
Filed from an investigation into "pr-review agent not working — many PRs pending review."
Summary
The pr-review agent correctly skips PRs whose CI is failing or in-progress (
decision: skip, reason: ci-pending | ci-failing). These skips are designed to be re-evaluated by a latercheck_suite:completedevent. But when CI settles green after the last review trigger fires — common on PRs where dev-lead is actively pushing fixes / re-running CI — no trigger re-fires, and the PR sits atREVIEW_REQUIREDwith green CI, never re-reviewed.The result is a growing backlog of PRs that look like "pr-review is down" but are actually just never re-triggered after their CI went green.
Evidence (2026-06-11)
PRs with fully green CI (zero
IN_PROGRESS/QUEUEDitems instatusCheckRollup) but no bot review andreviewDecision = REVIEW_REQUIRED:Trigger timeline for #569 (head
7d608fee):check_suite-triggered review run →{"pr":".../569","decision":"skip","reason":"ci-pending"}("CI checks still in progress") — legitimate at the time (dev-lead still pushing).successat 16:38:15).check_suite-triggered review run until an unrelated 17:36 run (skipped). The green state never produced a fresh review.The engine itself is healthy — every triggered run initializes the cascade fine (
engine: claude (triage: haiku 4.5 → deep: sonnet 4.6 + duck: o4-mini → audit: opus 4.7), auth OK,review decision: REVIEW_REQUIREDreached). This is purely a re-trigger gap, not an engine/auth/CLI failure.Why the safety net doesn't catch it
daily-pr-review-health.ymlis a reporter (opens issues about failed runs); it does not re-review stuck-green PRs, so it can't rescue this backlog.Proposed fix
Add a re-review path for PRs that were skipped
ci-pending/ci-failingand have since gone green. Options:REVIEW_REQUIREDPRs whose CI is now green and re-dispatches a review (reuselist-prs.sh/review-batch.sh).daily-pr-review-health.ymlfrom reporter → remediator for this specific case.check_suite:completedreliably re-triggers (the current path races against in-flight CI / dev-lead pushes).Immediate workaround
Manually dispatch
pr-review-trigger.ymlwith nopr_url(batch mode) to clear the current green backlog (#569, #518, #550, #549).Related
gh pr diffreturns HTTP 406 andreview-one-pr.sh:422exits 1 instead of falling back. Will file separately.Filed from an investigation into "pr-review agent not working — many PRs pending review."