GeezerVison

Problem

composer-compatibility.yml is the only compat workflow whose concurrency block has an unconditional cancel-in-progress: true. As a result, every push to main kills the Composer run that is already in progress on main. A full Composer run takes about an hour of wall time (run 37652576922: 16:30 → 17:37, 54 job-minutes), and main merges come in bursts, so almost no main commit gets a Composer verdict.

Main push runs from 2026-10-05 11:43Z to 2026-10-07 19:00Z (85 main commits), from the Actions API:

• 30 of the 68 Composer main runs cancelled since 10-05 12:00Z had already started jobs. Together they used 943 job-minutes and their results were thrown away. One example: the run created at 15:36:01Z ran for 31 minutes before the 16:07 push killed it.
• Main runs are the only rust-cache writers (save-if: ${{ github.ref == 'refs/heads/main' }}), so killing them mid-run also kills the cache save that Composer PR builds restore.
• Go uses the same push trigger without the in-progress cancel and got twice as many verdicts (24 vs 11) on the same commits.

Root cause

The concurrency block for this workflow was never switched to the convention the other compat workflows use and document. bun and vlt both say: "Supersede stale PR runs only: main runs are the only rust-cache writers, so push, dispatch and schedule runs are never cancelled mid-save."

Fix

One line, plus a comment that matches the bun and vlt wording:

cancel-in-progress: ${{ github.event_name == 'pull_request' }}

• PRs: behaviour is unchanged. A newer push to the same PR still supersedes the older run.
• main: the run in progress now finishes. A newer push waits as the one pending run, and any later push replaces it, so main's tip is always tested. This is the same batching that go, gradle, pdm, poetry, sbt, vlt and bun already use.
• Cost: at most one run in progress and one pending at any time, so main runs no faster than one per ~hour. The 943 job-minutes of killed work become completed verdicts instead.

Proof

• CI is fully green on b6c325f and Cursor Bugbot found nothing. The only failures were two Maven e2e legs, caused by Maven Central rate-limiting the runner (HTTP 429). Both passed on a single re-run.
• actionlint .github/workflows/composer-compatibility.yml is clean (v1.7.7), and the YAML parses to the intended concurrency mapping.
• The diff is limited to the concurrency block. No test, job, matrix leg or trigger changes, so every Composer test runs where it did before (PRs on the same paths, every main push, and dispatch). No required-check names change.

Not in this PR (follow-up candidates)

Every compat workflow grouped on github.ref (bun, go, gradle, pdm, poetry, sbt, vlt, and the bench job) still drops the pending main runs between bursts. In the same window: vlt 57/73 cancelled, sbt 43/52, bun 41/54, go 59/84, bench 52/73. #1018 fixed this for ci.yml by grouping push runs per commit. Doing the same for the compat matrices would cost roughly 10k job-minutes a day at the current merge rate (sbt ~197, bun ~116 and vlt ~102 job-minutes per run). That is an owner decision on cost vs. per-commit attribution, so it is left out of this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_016KMvUkRpp6WKLjgz3pTqqn

Generated by Claude Code

Generated by Claude Code