The four Claude AI workflows (ai_claude-backend-reviewer, ai_claude-orchestrator, ai_claude-rollback-safety, ai_claude-sdk-breaking-change) trigger on pull_request: [opened, synchronize] and none declare a concurrency group.
Every push to a PR launches four more jobs, and the previous four keep running against a commit nobody will merge. Observed directly: a force-push at 18:48 started a new set while the 18:46 set was still in progress on the same branch.
These workflows are not on the critical path — they are standalone, not required status checks, and have no merge_group trigger — so this is not a latency problem. It is runner contention. Measured aggregate queue on a PR run reaches 271 job-minutes with individual jobs waiting 20m, so superseded jobs holding runner slots inflate wall clock indirectly.
Fix: add a concurrency group with cancel-in-progress: true, matching the pattern cicd_1-pr.yml already uses.
Care needed for ai_claude-orchestrator, which also triggers on issue_comment and pull_request_review_comment. Cancelling in-progress runs there would kill an interactive @claude response mid-flight when a second comment arrives, so its group must keep comment-triggered runs isolated.
The four Claude AI workflows (
ai_claude-backend-reviewer,ai_claude-orchestrator,ai_claude-rollback-safety,ai_claude-sdk-breaking-change) trigger onpull_request: [opened, synchronize]and none declare aconcurrencygroup.Every push to a PR launches four more jobs, and the previous four keep running against a commit nobody will merge. Observed directly: a force-push at 18:48 started a new set while the 18:46 set was still in progress on the same branch.
These workflows are not on the critical path — they are standalone, not required status checks, and have no
merge_grouptrigger — so this is not a latency problem. It is runner contention. Measured aggregate queue on a PR run reaches 271 job-minutes with individual jobs waiting 20m, so superseded jobs holding runner slots inflate wall clock indirectly.Fix: add a
concurrencygroup withcancel-in-progress: true, matching the patterncicd_1-pr.ymlalready uses.Care needed for
ai_claude-orchestrator, which also triggers onissue_commentandpull_request_review_comment. Cancelling in-progress runs there would kill an interactive @claude response mid-flight when a second comment arrives, so its group must keep comment-triggered runs isolated.