Problem
The compiler emits queue: max by default on the concurrency groups it generates for jobs (agent, output, conclusion), per the docs: "Compiler-generated concurrency groups (agent, output, and conclusion jobs) emit queue: max by default so back-to-back triggers run sequentially rather than being dropped."
However, the generated top-level workflow concurrency group does not get queue: max:
concurrency:
group: "gh-aw-${{ github.workflow }}-${{ github.ref || github.run_id }}"
With the Actions default (queue: single), only the latest pending run per group survives — so for push-triggered workflows, back-to-back pushes displace queued runs entirely ("Canceling since a higher priority waiting request … exists") before any job-level concurrency is ever evaluated.
Impact
We hit this in production with a push-to-main schema-sync workflow whose agent diffs each push's payload: two merges landed ~3 minutes apart while a previous run was executing; the first merge's queued run was displaced by the second's, and since the replacement run only examined its own push payload, the displaced commit's changes were silently never processed. The run history shows a cancelled run and a successful (noop) run — nothing that looks like data loss unless you know to check.
This seems contrary to the intent expressed in the concurrency docs, where push triggers are listed with Cancel In Progress: No — the design goal appears to be that push-triggered runs are not lost, but the single pending slot loses them anyway.
Expected
The generated top-level concurrency group should also emit queue: max (respecting the existing features.group-concurrency-queue: false opt-out, and whatever platform conditionality falls out of #38341 for GHES).
Workaround
Override the top-level group manually in frontmatter:
concurrency:
group: "gh-aw-${{ github.workflow }}-${{ github.ref || github.run_id }}"
queue: max
Version
gh-aw v0.79.6
Problem
The compiler emits
queue: maxby default on the concurrency groups it generates for jobs (agent, output, conclusion), per the docs: "Compiler-generated concurrency groups (agent, output, and conclusion jobs) emit queue: max by default so back-to-back triggers run sequentially rather than being dropped."However, the generated top-level workflow concurrency group does not get
queue: max:With the Actions default (
queue: single), only the latest pending run per group survives — so for push-triggered workflows, back-to-back pushes displace queued runs entirely ("Canceling since a higher priority waiting request … exists") before any job-level concurrency is ever evaluated.Impact
We hit this in production with a push-to-main schema-sync workflow whose agent diffs each push's payload: two merges landed ~3 minutes apart while a previous run was executing; the first merge's queued run was displaced by the second's, and since the replacement run only examined its own push payload, the displaced commit's changes were silently never processed. The run history shows a cancelled run and a successful (noop) run — nothing that looks like data loss unless you know to check.
This seems contrary to the intent expressed in the concurrency docs, where push triggers are listed with Cancel In Progress: No — the design goal appears to be that push-triggered runs are not lost, but the single pending slot loses them anyway.
Expected
The generated top-level concurrency group should also emit
queue: max(respecting the existingfeatures.group-concurrency-queue: falseopt-out, and whatever platform conditionality falls out of #38341 for GHES).Workaround
Override the top-level group manually in frontmatter:
Version
gh-aw v0.79.6