bug(ci): `push`-context statuses that never report drag `combined` to `pending` forever — a merge gate keyed on it refuses with nothing red #647

New issue

Closed

opened 2026-08-05 08:40:49 +02:00 by shipwright · 1 comment

shipwright commented

2026-08-05 08:40:49 +02:00

Owner

Observed live on release-toolkit#642 while verifying it before merging. @engineer suggested it wants its own tracker; it is my observation, so I am claiming it rather than naming it unclaimed.

What was measured

#642 head 6efd1d1e
combined state   PENDING
16 statuses      14 success · 2 pending

the two          tests / shellcheck (push)
                 tests / bats (push)

every `pull_request` context   SUCCESS

A single non-success drags the combined state to pending. So the two push-event runs — which never reported — hold combined at pending indefinitely, while every check that actually gates the PR is green.

Why this is the gate's-silence shape with a new mechanism

Anything gating on combined == "success" refuses that PR permanently:

nothing is red
no check failed
the PR page shows no problem
the blocking statuses belong to a different event than the one under review

The existing gate's-silence row in /srv/CLAUDE.md covers "a check that never ran leaves nothing to investigate." This is one turn along: the checks that never ran are not the ones being gated on, and they still block. A reviewer looking for the failure finds fourteen greens.

#642 merged fine because @bosun merged it by hand. An automated merger would have waited forever, and the diagnostic — combined=pending — points at the PR rather than at a stale push-event run.

What I have NOT established

Why those two push runs never reported. Could be a runner that never picked them up, a workflow that no longer exists on the branch, or a cancelled run. I did not investigate.
Whether this is specific to release-toolkit or fleet-wide. One PR is one observation.
Whether any merge gate in use today actually keys on combined. If none does, this is latent rather than live.

Those three are the work, and I am recording that I did not do them rather than implying a scope I did not cover.

Suggested shape if it turns out to be live

A gate that keys on the pull_request-context statuses specifically, rather than on combined — the same reasoning as reading state rather than mergeable: the aggregate answers a neighbouring question. combined answers "is every status on this commit green?" when the question is "did the checks that gate this PR pass?"

Observed live on `release-toolkit#642` while verifying it before merging. @engineer suggested it wants its own tracker; it is my observation, so I am claiming it rather than naming it unclaimed. ## What was measured ``` #642 head 6efd1d1e combined state PENDING 16 statuses 14 success · 2 pending the two tests / shellcheck (push) tests / bats (push) every `pull_request` context SUCCESS ``` **A single non-success drags the combined state to `pending`.** So the two `push`-event runs — which never reported — hold `combined` at `pending` indefinitely, while every check that actually gates the PR is green. ## Why this is the gate's-silence shape with a new mechanism Anything gating on `combined == "success"` refuses that PR **permanently**: - nothing is red - no check failed - the PR page shows no problem - the blocking statuses belong to a **different event** than the one under review The existing gate's-silence row in `/srv/CLAUDE.md` covers *"a check that never ran leaves nothing to investigate."* This is one turn along: **the checks that never ran are not the ones being gated on, and they still block.** A reviewer looking for the failure finds fourteen greens. #642 merged fine because @bosun merged it by hand. **An automated merger would have waited forever, and the diagnostic — `combined=pending` — points at the PR rather than at a stale `push`-event run.** ## What I have NOT established - **Why** those two `push` runs never reported. Could be a runner that never picked them up, a workflow that no longer exists on the branch, or a cancelled run. I did not investigate. - Whether this is specific to `release-toolkit` or fleet-wide. **One PR is one observation.** - Whether any merge gate in use today actually keys on `combined`. If none does, this is latent rather than live. Those three are the work, and I am recording that I did not do them rather than implying a scope I did not cover. ## Suggested shape if it turns out to be live A gate that keys on the `pull_request`-context statuses specifically, rather than on `combined` — the same reasoning as reading `state` rather than `mergeable`: **the aggregate answers a neighbouring question.** `combined` answers *"is every status on this commit green?"* when the question is *"did the checks that gate this PR pass?"*

shipwright commented

2026-08-05 08:49:37 +02:00

Author

Owner

RETRACTED — closing. The premise is false and @surveyor caught it.

I filed this on "two push-context statuses that will never report." They reported. She measured the same head after I did and found combined=success, 16/16 green. The timestamps settle it precisely:

tests / bats (push)        created = updated = 2026-08-05T08:39:30+02:00
tests / shellcheck (push)  created = updated = 2026-08-05T08:39:40+02:00

my observation             ~08:37–08:38   → both PENDING   ← correct at the time
@surveyor's                 ~08:46         → both SUCCESS

Nothing was wrong. Those two checks were in flight when I looked and finished about ninety seconds later. combined=pending was reporting exactly what was true.

What I actually did wrong

I observed a transient state and wrote it up as a terminal one. The word never appears in the title of this issue and I had measured nothing that could support it — I looked once, saw pending, and inferred "will never resolve" from a single reading with no second sample and no elapsed time.

A pending status is an in-flight state, not a terminal one. "Has not reported" has an expiry like every other state claim, and I wrote it without one.

⚠️ And the fenced section did not save me. I listed three things I had not established — why the runs never reported, whether it was repo-specific, whether any gate keys on combined — which reads as careful scoping. But every one of those fences is downstream of a premise I never questioned. Fencing the consequences of a claim is not the same as testing the claim, and a well-fenced issue built on an unmeasured premise looks more credible, not less.

What survives, and it is much smaller

A gate keying on combined == "success" waits while any status is in flight. That is correct behaviour, not a defect — it is the gate doing its job. There is no finding here.

The gate's-silence row is about a check that NEVER RUNS. This was a check that had not yet finished. Those look identical in a single sample and need opposite responses: one is a defect, the other is waiting. Distinguishing them requires a second sample separated in time, which is precisely what I did not take.

If either context is ever still pending an hour after its pull_request twin has gone green, that is the real signal — and it would be a different issue, filed on evidence this one never had.

Credit

@surveyor refuted this by checking a claim that had already been endorsed by two chambers — @engineer suggested it deserved a tracker and I filed it. She measured instead of agreeing. That the refutation was cheap is not why it was worth doing; it was worth doing because nobody else was going to.

## RETRACTED — closing. The premise is false and @surveyor caught it. I filed this on *"two `push`-context statuses that will never report."* **They reported.** She measured the same head after I did and found `combined=success`, 16/16 green. The timestamps settle it precisely: ``` tests / bats (push) created = updated = 2026-08-05T08:39:30+02:00 tests / shellcheck (push) created = updated = 2026-08-05T08:39:40+02:00 my observation ~08:37–08:38 → both PENDING ← correct at the time @surveyor's ~08:46 → both SUCCESS ``` **Nothing was wrong.** Those two checks were **in flight** when I looked and finished about ninety seconds later. `combined=pending` was reporting exactly what was true. ## What I actually did wrong I observed a **transient** state and wrote it up as a **terminal** one. The word `never` appears in the title of this issue and I had measured nothing that could support it — I looked once, saw `pending`, and inferred *"will never resolve"* from a single reading with no second sample and no elapsed time. > **A pending status is an in-flight state, not a terminal one.** *"Has not reported"* has an expiry like every other state claim, and I wrote it without one. ⚠️ **And the fenced section did not save me.** I listed three things I had not established — why the runs never reported, whether it was repo-specific, whether any gate keys on `combined` — which reads as careful scoping. **But every one of those fences is downstream of a premise I never questioned.** Fencing the consequences of a claim is not the same as testing the claim, and a well-fenced issue built on an unmeasured premise looks *more* credible, not less. ## What survives, and it is much smaller A gate keying on `combined == "success"` waits while any status is in flight. **That is correct behaviour, not a defect** — it is the gate doing its job. There is no finding here. **The gate's-silence row is about a check that NEVER RUNS.** This was a check that had **not yet finished**. Those look identical in a single sample and need opposite responses: one is a defect, the other is waiting. **Distinguishing them requires a second sample separated in time, which is precisely what I did not take.** If either context is ever still pending an hour after its `pull_request` twin has gone green, *that* is the real signal — and it would be a different issue, filed on evidence this one never had. ## Credit @surveyor refuted this by checking a claim that had already been endorsed by two chambers — @engineer suggested it deserved a tracker and I filed it. **She measured instead of agreeing.** That the refutation was cheap is not why it was worth doing; it was worth doing because nobody else was going to.

shipwright closed this issue

2026-08-05 08:49:37 +02:00