fix(ci): scope minimize-reviews concurrency by event name#4174
Conversation
A single review action fires pull_request_review and pull_request_review_comment at the same instant; sharing one PR-scoped concurrency group made the siblings cancel each other, sometimes leaving a SHA with only cancelled runs. 🤖 Generated with Claude Code
|
@claude review |
|
tl;dr: CI failure is a pre-existing Windows-only flake in Root cause: The test timed out at the 5s thread-timeout while inside Fix: Re-run the Log excerpt``` All other jobs in run 26002021291 (ubuntu 3.10/3.13, lowest-direct deps, MCP conformance, integration, smoke) passed. PR diff (for context)```diff
Workflow-only change; cannot affect Python unit tests. |
A single review action fires two events at the same instant —
pull_request_review(submitted) andpull_request_review_comment(created). Because theminimize-resolved-reviewsconcurrency group was keyed only on PR number, both sibling runs landed in the same group withcancel-in-progress: trueand cancelled each other. Usually one survives, but under a burst both siblings can endcancelled, leaving a commit with no successful run of this workflow at all (observed on #4060'scodex/keycloak-fixbranch — e.g. runs 2767 and 2768 for the same SHA both cancelled).Appending
github.event_nameto the concurrency group keeps the two sibling event types in separate groups so they no longer cancel each other. Same-PR runs of the same event still supersede cleanly, and the last run of each type always completes.🤖 Generated with Claude Code