development push runs are still being cancelled after #597 and the 13 caller fixes (27 of 52)

[rubenvdlinde]

Follow-up to #526 / #597. The cancellation is reduced but NOT eliminated, and I do not yet know why. Filing the measurement rather than another claim that it is fixed — I have now claimed that twice and been wrong twice.

What was changed

1. fix(quality): a push to development must reach a verdict #597 — cancel-in-progress: ${{ github.event_name != 'push' }} on the shared quality.yml.
2. 13 caller PRs — the same expression on each app's own code-quality.yml, because a caller's concurrency cancels the whole run before the called workflow's setting applies. 8 apps declare no caller concurrency and were already covered by fix(quality): a push to development must reach a verdict #597.

Both are live: verified on all 13 development branches and on .github main.

What is still happening

Push runs on development, counted strictly after each repo's own fix merged:

completed = 52    cancelled = 27

Concrete example — opencatalogi, both commits after its fix merged at 08:51:18Z:

created	head	outcome
10:00:07	0f2ea8ad	cancelled at 10:00:57
10:00:56	fae8f364	ran to completion

The workflow file at 0f2ea8ad carries cancel-in-progress: ${{ github.event_name != 'push' }}. A newer push superseded it anyway.

But it is not uniform

Overlapping push runs do both complete in some apps:

app	run A	run B	both completed?
humaniq	07:53:59 → 08:47:49	07:57:04 → 09:29:38	yes
larpinq	09:58:46 → 10:36:49	10:04:50 → 10:54:17	yes

And cancellations still occur in apps with no caller concurrency at all (decidiq 08:57:44 cancelled 29s after a second push started; stackiq likewise), where only #597 applies.

So the behaviour splits in a way neither fix explains.

Hypotheses, untested

1. The expression is coerced to a truthy string. ${{ github.event_name != 'push' }} may reach cancel-in-progress as the string "false", which is truthy. GitHub documents expressions here as supported (cancel-in-progress: ${{ !contains(github.ref, 'release/') }}), so this would be a coercion edge rather than a documented one.
2. A reusable workflow's concurrency is evaluated in a context where github.event_name is not push, making the shared-workflow half inert for a different reason than the caller half.
3. Something else cancels these runs. I searched the fleet workflows for a canceller and found none.

Suggested next step

A controlled probe on one repo — a literal cancel-in-progress: false on the caller, then two pushes seconds apart — discriminates hypothesis 1 from the others in one run. That is a five-minute experiment and worth more than further reasoning from the fleet's mixed data.

What is NOT in doubt

The original problem is real and the direction is right: before any of this, openregister was 12/12 cancelled and learniq 10/12. Once runs started completing, one day surfaced a phpmd violation and a broken flow-create E2E (openregister), 15 schema-invalid manifest actions (dossiq), 8 untranslated strings (launchpad) and an eslint error (learniq) — none of which anything had reported.