fix(hybrid-gate): key the concurrency group by SHA on push - #32
Merged
Conversation
On a default branch the ref is constant, so a ref-keyed group made every merge cancel the previous commit's gate. Measured in aletheia over one window, two consecutive merges each lost their verdict entirely -- 53ba8110b and 8dd94b02c, where the caller's own jobs went green and every job defined here was cancelled. The split falling exactly on the caller/callee boundary is what identified the cause: aletheia's caller had already SHA-keyed its pushes for precisely this reason, and this group had not, so the fix was half-applied and the half that mattered -- fmt, check, clippy, nextest, the trailer logic, i.e. what the required context actually attests -- kept being cancelled. It is worse than a missing verdict. `Evaluate gate result` fails on a cancelled upstream, so the commit reports RED with nothing wrong, which teaches everyone to discount red on a default branch. aletheia has since made that reporting distinguishable (aletheia#6706), but that only stops the two looking alike; it does not restore the lost verdict. This does. PRs keep ref-keying, so a force-push still supersedes its own in-flight run. Refs: aletheia#6701
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs aletheia#6701. Fleet-wide blast radius — every adopting repo consumes this workflow. Flagging that plainly at the top.
Finding
On a default branch
github.refis constant, so a ref-keyed concurrency group makes every merge cancel the previous commit's gate.Measured in aletheia over one window — two consecutive merges, each losing its verdict entirely:
53ba8110b8dd94b02cThe split falling exactly on the caller/callee boundary is what identified the cause. aletheia's caller had already SHA-keyed its pushes for precisely this reason, with a comment explaining it. This group had not — so the fix was half-applied, and the half that mattered kept being cancelled: fmt, check, clippy, nextest, the trailer logic. That is what the required context actually attests.
Why it is worse than a missing verdict
Evaluate gate resultfails on a cancelled upstream, so the commit reports RED with nothing wrong. A red that nobody caused teaches everyone to discount red on a default branch — which is the one property a required check depends on.aletheia has since made cancelled distinguishable from failed (aletheia#6706), but that only stops the two looking alike. It does not restore the lost verdict. This does.
Change
Mirrors the key aletheia's caller already uses. PRs keep ref-keying, so a force-push still supersedes its own in-flight run — only pushes get per-commit groups.
Adoption note
Repos that pin this workflow by SHA (aletheia does, deliberately) do not inherit the fix until their pin is bumped. I will bump aletheia's in a follow-up once this lands; other adopters need the same.