ci: zero checks is not zero failures, on the path that merges - #3314
Merged
Conversation
named a path but not quiet 128 -> 131 The three are the ones added in the previous commit: the empty-rollup refusal and the merge-failure count in auto-merge-ready-prs.yml, and the no-checks-yet column in pr-dashboard.yml. Each names a path it reads, and none is quiet -- they are in the census's good class, and the count moving is the census noticing them arrive. The gate asked for this in the same commit and I gave it the next one, because the first was already pushed and this repository does not force-push. Refs #3248 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-05 17:56:56 UTC
Summary
Seal Status
|
gHashTag
enabled auto-merge (squash)
September 5, 2026 17:57
This was referenced Sep 5, 2026
gHashTag
pushed a commit
that referenced
this pull request
Sep 5, 2026
Two sessions of this loop ran concurrently and picked the same three tasks from the same list of recommendations, opening PRs for all of them (#3314, #3317). Nothing in the flow says who is working on what. `tri loop claim <name>` uses the one atomic operation git gives over a shared remote: creating a ref that does not exist. Exit 0 it is yours, 1 someone has it and the line names them, 2 the attempt could not be made -- which is not the same as being refused. THE OBVIOUS VERSION DOES NOT LOCK, and I measured it before writing this one. Pushing `origin/master` to the claim tag succeeds for the SECOND claimant too: git treats re-pushing the same value to an existing tag as a no-op and exits 0, so both sessions believe they hold it. Two sessions of this loop sit on the same `origin/master` almost by definition, so that lock would have been worse than none -- it reports success. The claim is therefore a commit no other claimant can produce: an empty tree with a message naming host, pid and HEAD. Measured: ALPHA exit 0, BETA exit 1 with the holder named. A refused push with NO holder exits 2, not 1. That is a broken push rather than a lost race, and reporting it as HELD would send the next session away from work nobody is doing. Two mutants killed -- borrowing the claim value from an existing ref, and reporting a broken push as held. The second test could not kill anything until it was fixed: it sliced from the first `match holder` to end of file and asserted `contains("exit(2)")`, which four unrelated exit-2 sites satisfy. CENSUS. Three moved and they are not all mine: fetches files read 43 -> 44 MINE: cli/tri/src/loopclaim.rs quiet named a path but not quiet 128 -> 127 already moved on master shell run: steps 235 -> 234 already moved on master A clean `origin/master` worktree fails `census pin --gate` with the last two before any change of mine, so the pre-commit hook has been failing for every author since a workflow edit landed unblessed. This commit carries the bless it inherited and says so rather than passing it on. Getting there took four wrong turns worth recording: `census pin` WITHOUT `--gate` exits 0 whatever moved, and I read that non-verdict as "nothing moved" twice -- once as the control that supposedly cleared master. Refs #3331 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Sep 5, 2026
gHashTag
added a commit
that referenced
this pull request
Sep 6, 2026
Two sessions of this loop ran concurrently and picked the same three tasks from the same list of recommendations, opening PRs for all of them (#3314, #3317). Nothing in the flow says who is working on what. `tri loop claim <name>` uses the one atomic operation git gives over a shared remote: creating a ref that does not exist. Exit 0 it is yours, 1 someone has it and the line names them, 2 the attempt could not be made -- which is not the same as being refused. THE OBVIOUS VERSION DOES NOT LOCK, and I measured it before writing this one. Pushing `origin/master` to the claim tag succeeds for the SECOND claimant too: git treats re-pushing the same value to an existing tag as a no-op and exits 0, so both sessions believe they hold it. Two sessions of this loop sit on the same `origin/master` almost by definition, so that lock would have been worse than none -- it reports success. The claim is therefore a commit no other claimant can produce: an empty tree with a message naming host, pid and HEAD. Measured: ALPHA exit 0, BETA exit 1 with the holder named. A refused push with NO holder exits 2, not 1. That is a broken push rather than a lost race, and reporting it as HELD would send the next session away from work nobody is doing. Two mutants killed -- borrowing the claim value from an existing ref, and reporting a broken push as held. The second test could not kill anything until it was fixed: it sliced from the first `match holder` to end of file and asserted `contains("exit(2)")`, which four unrelated exit-2 sites satisfy. CENSUS. Three moved and they are not all mine: fetches files read 43 -> 44 MINE: cli/tri/src/loopclaim.rs quiet named a path but not quiet 128 -> 127 already moved on master shell run: steps 235 -> 234 already moved on master A clean `origin/master` worktree fails `census pin --gate` with the last two before any change of mine, so the pre-commit hook has been failing for every author since a workflow edit landed unblessed. This commit carries the bless it inherited and says so rather than passing it on. Getting there took four wrong turns worth recording: `census pin` WITHOUT `--gate` exits 0 whatever moved, and I read that non-verdict as "nothing moved" twice -- once as the control that supposedly cleared master. Refs #3331 Co-authored-by: lab <lab@example.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This was referenced Sep 6, 2026
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
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.
Fixes both readers in #3248.
auto-merge-ready-prs.yml— a PR nothing had run on was "Ready to merge"FAILING was computed over the status rollup and 0 was treated as clean. Measured
with the workflow's own jq:
null)The running case was already right and deliberately so —
null != "SUCCESS"istrue in jq. Only the empty set was wrong.
Its merge loop ended
|| echo "Failed to merge PR #$pr", so the step exited 0whether every merge succeeded or every one failed: a batch that merged nothing
reported green. It now counts both and exits 1 if any failed.
pr-dashboard.yml— the columns did not partitionREADY was
all(SUCCESS or SKIPPED or null).allover an empty array is true,so a PR with no checks was READY; the
nullarm put still-running PRsthere too — and the same PR was then counted in READY and PENDING, while the
three columns were printed as a breakdown of TOTAL.
Each PR now lands in exactly one column, "no checks yet" has its own, and the
table prints a warning when the four stop summing to TOTAL rather than leaving a
reader to add them up.
Census
The three added steps moved
named a path but not quiet128 → 131 and areblessed in the second commit, naming the number. The gate asked for it in the
same commit; it got the next one, because the first was already pushed and this
repository does not force-push.
Refs #3248