Stop cancelling in-progress Composer runs on main

[Mikola Lysenko (mikolalysenko)]

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:

workflow	main push runs	cancelled	success	failure
Composer (cancel-in-progress: true)	84	72	11	1
Go (same push trigger, PR-only cancel)	84	59	24	0
npm / pnpm / Pipenv (run_id group)	84 each	0	83–84	0–1

• 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

---

Note

Low Risk
Workflow-only concurrency tweak with no job matrix, trigger, or application code changes.

Overview
Composer compatibility CI no longer cancels in-progress main push runs when another commit lands on main. cancel-in-progress is now ${{ github.event_name == 'pull_request' }}, matching other compat workflows (e.g. bun, vlt).

PR behavior is unchanged: newer pushes on the same PR still cancel the older run. On main, the active run finishes (important because those jobs are the only rust-cache writers via save-if), so long Composer matrix runs are not discarded mid-flight and cache saves can complete.

^{Reviewed by Cursor Bugbot for commit b6c325f. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit b6c325f. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Resolved: the two Maven e2e legs that failed on Maven Central 429s passed on a single re-run (run 37671925752, attempt 2), and ci-ok is green. Every check on b6c325f now passes.

For the record, the first attempt failed with:

• e2e (ubuntu-latest, e2e_vendor_maven_build, maven, 3.6.3): Could not find artifact org.apache.commons:commons-text:jar:1.10.0 in central while resolving maven-dependency-plugin:3.6.1.
• e2e (ubuntu-latest, e2e_vendor_maven_build, maven, 3.9.16): status code: 429, reason phrase: Too Many Requests from repo.maven.apache.org on all three warm-up retries.

Neither failure was caused by this PR, which only changes the concurrency block in composer-compatibility.yml. Caching ~/.m2 for the Maven e2e legs would stop these legs depending on Central on every run. That is a separate follow-up.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] Ready for review at b6c325f7fad6123f4c9e985af47a66e96d504a5d.

• CI: all green: 234 success / 4 skipped / 0 failing or pending, ci-ok green. The two e2e_vendor_maven_build legs failed on attempt 1 with a Maven Central 429 Too Many Requests during fixture warm-up (infra) and passed on re-run.
• Bugbot reviewed b6c325f: no new issues. No open review threads. Already approved by Tanmay Singla (@Tanmay182003) on this head.
• Mergeable: clean.

---

Generated by Claude Code