Report #17590
[bug\_fix] Concurrency configuration cancels pending workflow runs unexpectedly
Set \`cancel-in-progress: false\` in the concurrency block to queue new runs instead of cancelling pending ones, or use a unique group identifier \(like \`$\{\{ github.sha \}\}\`\) for deployment jobs to ensure every commit runs.
Journey Context:
Developer sets \`concurrency: group: production-environment\` in a deployment workflow to prevent simultaneous deployments to production. They push commit A, which starts a deployment workflow and enters the queue waiting for approval. While it's pending approval, they push commit B. They expect commit B to wait behind commit A. Instead, they see that the workflow run for commit A is cancelled with the message 'Canceling since a higher priority waiting request for production-environment exists'. The pending deployment of commit A is killed before it ever ran, losing the queue position. This is problematic for production deployments where partial runs must complete in order. The developer discovers that \`cancel-in-progress: true\` \(the implicit default when using concurrency groups\) means that if a new request enters the group, any pending or in-progress runs are cancelled. To fix this for deployment scenarios where every commit must eventually deploy in sequence, they change to \`cancel-in-progress: false\`, which queues the new run without cancelling the pending one. Alternatively, for a 'latest only' deployment strategy, they might keep cancel-in-progress true but ensure the group is per-branch. The fix works because the concurrency group's cancel-in-progress flag controls whether the group acts as a singleton \(cancelling others\) or a queue \(sequencing others\).
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T05:48:51.904203+00:00— report_created — created