PR Review Agent — failures detected 2026-10-01 #1988

Convergence latency (deterministic)

Workflow duration across 840 completed run(s) in the window — computed by pr_review_health.sh, not the model.

Run-outcome mix by triggering event

pr-review run conclusions over the window, split by the event that triggered each run — computed deterministically by pr-review-outcomes.sh, not the model. A high cancelled share means runs were evicted while PENDING (concurrency admits one running + one pending per group); a cancelled run is non-blocking but historically rendered as a failing check (#1421).

Sweep hit-rate (deterministic)

How often the pr-review-sweep scheduled backstop actually had to re-review a PR — computed deterministically by pr-review-sweep-metrics.sh, not the model. The scheduled (cron) path re-dispatches only for genuinely un-eventable cases (GitHub-App / cross-repo checks like SonarCloud that emit no workflow_run); the workflow_run fast path handles every eventable case, so a scheduled re-dispatch is always a case the fast path did not cover.

Interpretation: a low rate confirms the timer stays exception-only (the event fast path is carrying the load); a rising rate is a signal that an eventable case is leaking onto the timer — a hole in the narrowing worth investigating.

1. Executive Summary

Status: WARNING
Period: 2026-09-30 16:58Z to 2026-10-01 13:07Z (about 20 hours, last 1 day)
Result: 8 of 841 runs failed (0.95%). 420 succeeded (50%), 297 were cancelled (35%), about 115 were skipped (14%), and 1 was in progress.

Key findings:

• No failure logs were supplied. The "Failed Run Logs" section is empty, so the root cause of the 8 failures cannot be determined and no error messages can be quoted.
• 297 runs (35%) were cancelled, which is far higher than the failure count. This is most likely concurrency cancellation from bursts of check_suite/pull_request events. It is not confirmed because the workflow source shown has no concurrency: block (the reusable pr-review.yml may define one).
• Failures are bursty, not steady: 4 fall in 03:17–03:41Z on 10-01, and 4 are isolated (09-30 18:09, 19:40, 22:20 and 10-01 10:52).
• Three failures are followed by a success within about 7–15 seconds (#85806→#85807, #86033→#86034, #86202→#86203). Those runs probably covered the same PR and were recovered by the next trigger, so the failures look transient.
• The longest run was exactly 20m0s, and p95 is 14m10s. A run hitting exactly 20m looks like a timeout cap.

Action required: Re-run the report with the failed-run logs (gh run view <id> --log-failed for the 8 runs below) and confirm where the cancellation concurrency is configured.

2. Failure Breakdown

3. Error Patterns

• No quotable errors. The log section is empty, so no step or script can be tied to an error.
• Timing pattern:
  • The 03:17–03:41Z cluster (#86202, #86204, #86258, #86299) coincides with heavy cancellation and skip activity. Dozens of runs were cancelled between 03:25 and 03:41Z.
  • Likely causes are a burst of PR pushes, or a rate or quota limit hit during that burst. Neither is confirmed.
• Cancellation pattern:
  • Cancelled runs come in tight bursts, often several within seconds (for example 11:06–11:30Z and 00:03–00:29Z on 10-01).
  • That is consistent with cancel-in-progress concurrency superseding older runs when check_suite, pull_request_review and pull_request events arrive together.
  • These are expected unless the cancelled runs were mid-review.
• Skipped runs (about 115): These are probably the reusable's gate conditions filtering events that need no review. This is expected.

4. Token Scope Analysis

• Scopes currently present (from the workflow permissions: block): contents: read, pull-requests: write, checks: read. The workflow uses secrets: inherit, so org secrets are also passed to the reusable.
• No gh auth status output was in the logs.
• Scopes that appear missing: None can be identified, because no 401/403 errors were provided.
• Recommendations:
  • Once logs are available, grep for 403, Resource not accessible by integration and read:org.
  • Only add scopes if such errors appear. If the reusable posts review comments or labels, issues: write might be needed.
  • Do not widen permissions speculatively.

5. Recommendations

1. [HIGH] Collect the failure logs.
   • Run gh run view <id> --log-failed for #86367, #86299, #86258, #86204, #86202, #86033, #85832 and #85806.
   • Fix the report-generation step so "Failed Run Logs" is populated. It is currently empty even though 8 failures exist.
   • Impact: lets the next report identify the root cause. Failures are 0.95% now, so urgency is HIGH rather than CRITICAL.
2. [MEDIUM] Audit cancellation volume.
   • Check the concurrency: group in pr-review.yml@pr-review/v1-next.
   • Key the group on PR number so a push only cancels older runs for the same PR. Confirm that cancel-in-progress does not kill runs mid-review for check_suite events.
   • Impact: fewer wasted runs, since 35% are cancelled, and fewer lost reviews.
3. [MEDIUM] Reduce redundant triggers.
   • check_suite: completed fires for every check suite across the repo, producing many skipped and cancelled runs.
   • Filter early in the reusable, or restrict the trigger. Do not change the stub's trigger block beyond what AGENTS.md allows.
   • Impact: lower Actions minutes and less noise.
4. [LOW] Investigate the 20m0s maximum run.
   • Identify that run. If it was a timeout, review timeout-minutes and the engine call duration.
   • Consider whether p95 of 14m10s warrants a per-stage budget.
   • Impact: avoids silent timeouts.
5. [LOW] Watch the 03:17–03:41Z cluster. If failures recur in bursts, check engine or API rate limits and add retry/backoff for transient errors.

6. Health Score

Health: 8/10 — Only 0.95% of runs failed, but with no logs the cause is unknown, and 35% of runs were cancelled.