Label PR review state workflow: shared concurrency group starves per-PR reconciliation (queued runs cancelled during busy periods)

[zoomote]

Bug: shared concurrency group starves per-PR reconciliation — queued runs are cancelled before executing

Summary

The Label PR review state workflow uses a single repo-wide concurrency group:

concurrency:
  group: label-pr-review-state
  cancel-in-progress: false

GitHub keeps at most one queued run per concurrency group: when a new run is queued while another is already waiting, the older queued run is cancelled. This repo triggers the workflow constantly (PR events, CodeRabbit issue_comment/pull_request_review events, workflow_run completions, hourly cron — 21,000+ runs, often several per minute), so a queued run for any specific PR is frequently superseded and cancelled before it ever starts. The affected PR then goes unreconciled until the hourly schedule sweep happens to survive the queue.

Observed on

PR #1664 (perf(webview): stop task history globalState writes), 2026-09-19 UTC:

• 23:37:36 — head 6be655a pushed; pull_request_target: synchronize reconcile ran at 23:37:46 while CI was still pending → state labels stripped, guide comment set to "Wait for required CI checks".
• 23:48:01 — Code QA Roo Code completed green; its workflow_run completion queued reconcile run #20986 at 23:48:03 → cancelled at 23:48:21 while still queued, superseded by a newer trigger. Earlier workflow_run reconciles (e.g. after CodeQL at 23:39) ran while other required checks were still pending.
• 23:48→00:02 — no successful reconcile touched the PR; awaiting-coderabbit / coderabbit-review-active were never applied despite green CI.
• 00:05 — a manual workflow_dispatch reconcile for PR perf(webview): stop task history globalState writes #1664 (run #21057) was also cancelled while queued, 24 seconds after creation.
• 00:02 — the hourly cron sweep finally reconciled the PR and applied the labels.

Net effect: the PR sat without its CodeRabbit review-state labels for ~15 minutes after CI passed, and would have waited up to an hour if the cron hadn't landed.

Root cause

All triggers — per-PR events, CodeRabbit comment triggers, workflow_run completions, workflow_dispatch, and the repo-wide cron sweep — share one concurrency group. High event volume means the single queue slot is almost always contested, and GitHub's queued-run replacement semantics silently drop the losing run. cancel-in-progress: false only protects the running run, not the queued one.

Impact

• Any PR's reconciliation (labels, review-guide comment, review-gate status, CodeRabbit activation label) can be silently delayed up to the hourly cron during busy periods.
• workflow_run triggers that fire while CI is only partially complete are wasted; the final trigger that would observe green CI may be the one that gets cancelled.
• Manual workflow_dispatch restarts — the documented maintainer recovery path — are equally unreliable.

Suggested fix

Key the concurrency group per PR for PR-scoped events so unrelated activity can't starve a given PR, keeping a shared group only for the repo-wide sweeps:

concurrency:
  group: >-
    label-pr-review-state-${{
      github.event.pull_request.number
      || github.event.issue.number
      || github.event.inputs.pull_request_number
      || 'sweep'
    }}
  cancel-in-progress: false

Notes:

• workflow_run events may resolve to multiple PRs; they could use a per-triggering-workflow key (e.g. suffix github.event.workflow_run.id) since the reconcile logic already resolves the exact PRs from the run.
• Alternatively, if dropped runs are acceptable for high-frequency triggers, add a final always-run "catch-up" step — but per-PR keys are the direct fix.

Environment

• Workflow: .github/workflows/label-pr-review-state.yml
• Repo: Zoo-Code-Org/Zoo-Code (default branch main)

Related: #884 (stale check-run handling, fixed) — same workflow, distinct failure mode.

[PierrunoYT]

Working on it!