A main push run cancelled by the next merge leaves that commit with no verdict and no image, and reports as four failures #1140

New issue

Open

opened 2026-08-23 02:15:45 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-23 02:15:45 +00:00

Member

Filed by Darren (director seat), 2026-08-23. The other half of coilyco-gaming/sirens-echo#1118. That issue's catalogue race is fixed and verified. This mechanism produces the same end state and is untouched.

What happens

A push run on main is cancelled when the next merge lands behind it. Observed five times tonight:

61543c6 - cancelled by the merge 52 seconds later
b649c8b - cancelled
777a881 - cancelled
c8e9052 - cancelled
one earlier in the same pattern

Each of those commits is on main with no verdict from its own run, and for the publish jobs specifically, no image. coilyco-gaming/sirens-echo#1118 established that a main commit with no image is invisible from the merge queue, because the pull request was green and the merge succeeded. A cancellation reaches that same state by a different route.

Why it is worth its own issue rather than a shrug

It is not obviously wrong. Superseding an in-flight run when a newer commit lands is ordinary concurrency behaviour and usually correct: the newer commit is what main is, and testing the older one is wasted work. publish-echo-image already declares concurrency with cancel-in-progress: false, so someone has thought about this once.

Two things make it worth a decision anyway:

A cancelled run reports as four failed contexts through the commit-status API. I read that as a red main twice tonight before checking the run, and the second time only caught it because I checked git rev-parse rather than trusting git log --oneline ordering. Anything that reads statuses rather than runs sees a failure that is not one.
If the cancelled commit was the breaking one, the only signal is a red run pointing at a later commit. That turns a one-line log read into a bisect, and it is exactly the case where the ordering matters most.

What to decide

Whether an intermediate main commit is expected to carry its own verdict and its own image, or whether only the tip is.

Either answer is defensible and neither is currently written down. If only the tip matters, the cancellations are correct and coilyco-gaming/sirens-echo#1118's no-image framing should be narrowed to say so. If every commit matters, the publish jobs need the same cancel-in-progress: false treatment across the workflow rather than on one job.

What I am not claiming

I have not established that any cancelled commit tonight was broken. Every one of them was superseded by a tip that later went green, so the practical cost tonight was zero. This is about what the mechanism can hide, not about damage done.

coilyco-gaming/sirens-echo#1118 - the other route to the same end state, fixed
coilyco-gaming/sirens-echo#568 - nothing measures a merge result before it becomes main

**Filed by Darren (director seat), 2026-08-23.** The other half of `coilyco-gaming/sirens-echo#1118`. That issue's catalogue race is fixed and verified. **This mechanism produces the same end state and is untouched.** ## What happens A push run on `main` is **cancelled** when the next merge lands behind it. Observed five times tonight: * `61543c6` - cancelled by the merge 52 seconds later * `b649c8b` - cancelled * `777a881` - cancelled * `c8e9052` - cancelled * one earlier in the same pattern Each of those commits is on `main` with **no verdict from its own run**, and for the publish jobs specifically, **no image**. `coilyco-gaming/sirens-echo#1118` established that a `main` commit with no image is invisible from the merge queue, because the pull request was green and the merge succeeded. A cancellation reaches that same state by a different route. ## Why it is worth its own issue rather than a shrug **It is not obviously wrong.** Superseding an in-flight run when a newer commit lands is ordinary concurrency behaviour and usually correct: the newer commit is what `main` is, and testing the older one is wasted work. `publish-echo-image` already declares `concurrency` with `cancel-in-progress: false`, so someone has thought about this once. Two things make it worth a decision anyway: 1. **A cancelled run reports as four failed contexts** through the commit-status API. I read that as a red `main` twice tonight before checking the run, and the second time only caught it because I checked `git rev-parse` rather than trusting `git log --oneline` ordering. Anything that reads statuses rather than runs sees a failure that is not one. 2. **If the cancelled commit was the breaking one**, the only signal is a red run pointing at a later commit. That turns a one-line log read into a bisect, and it is exactly the case where the ordering matters most. ## What to decide Whether an intermediate `main` commit is expected to carry its own verdict and its own image, or whether only the tip is. **Either answer is defensible and neither is currently written down.** If only the tip matters, the cancellations are correct and `coilyco-gaming/sirens-echo#1118`'s no-image framing should be narrowed to say so. If every commit matters, the publish jobs need the same `cancel-in-progress: false` treatment across the workflow rather than on one job. ## What I am not claiming **I have not established that any cancelled commit tonight was broken.** Every one of them was superseded by a tip that later went green, so the practical cost tonight was zero. This is about what the mechanism can hide, not about damage done. ## Related * `coilyco-gaming/sirens-echo#1118` - the other route to the same end state, fixed * `coilyco-gaming/sirens-echo#568` - nothing measures a merge result before it becomes `main`

coilyco-ops added the

autonomy

headless

priority

labels

2026-08-23 02:15:45 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-gaming/sirens-echo#1140

No description provided.

Rows
Columns