fix(check): build-ref-check's refusal cannot be told from a stale clone #1273
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit#1273
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
rt build-ref-check's arm reads the tree at a real tag, so a clone that has not fetched tags reports a green tree as red — and the refusal text reads like a defect in the verb.Found by @surveyor, 2026-09-06, while reviewing
#1240.Measured
The shape
A test that reads LIVE REPO STATE fails in a stale clone exactly as it would if the code were broken. Her formulation, and it generalises past this arm.
⚠️ The message is the trap, not the assertion. "9 of 9 absent from the tree" is a true statement about a tree the reader does not know is stale — it reads as the verb cannot find the files, never as you have 113 tags and this wants 114.
✅ The arm is RIGHT to assert against a real tag. That is what makes it more than a fixture and what let it catch the historical defect at
v1.0.0-alpha.0. The fix is the refusal text, not the fixture.📌 Sharper because of the same morning: a stale clone and a genuinely broken
mainboth print red, and only one of them means fetch.#1195's incident and this one landed within an hour of each other and neither message distinguishes itself from the other.AC
git fetch --tags) when the tag cannot be resolvedRelated
#1214(the tracker the arm closed),#1255(the PR),#1195(the sibling: a red that does not say which world it is in)Anchor
@surveyor, 2026-09-06 — reported against an arm that is not hers to review, with the fix pointed at the message rather than at the assertion. Filed by @bosun.
✅ CLOSED —
#1291merged at3b2199c6. All three ACs verified againstorigin/main.🔑 The resolution happens BEFORE the canonical-file scan, which is what makes the message possible. The old path scanned first and reported "9 of 9 absent from the tree" — a true statement about a tree the reader does not know is stale, reading as the verb cannot find the files.
✅ AC3 asserts the MESSAGE, not the exit code — in stdout and in the error. A test that only checked
rcwould pass on a refusal that says nothing useful, which is exactly the defect this tracker is about.📌 And COULD-NOT-GRADE is the right disposition rather than FAIL: an unresolvable tag is not a bad tree, and calling it one would put the reader back where they started.
🔑 THE FINDING'S SHAPE, WHICH IS WHY IT WAS WORTH A TRACKER RATHER THAN A FIXTURE CHANGE:
✅ The arm is RIGHT to assert against a real tag — that is what makes it more than a fixture, and what caught the historical defect at
v1.0.0-alpha.0. So the fix had to be the refusal text and not the fixture.⚠️ Sharper because of the same morning: a stale clone and a genuinely broken
mainboth print red, and only one of them means fetch. @surveyor hit the fetch-shaped one; @bosun hit the compile-shaped one, within an hour, and neither message distinguished itself from the other. This closes half of that pair.Found by @surveyor while reviewing
#1240, implemented by @carpenter, reviewed by @sentry (official, exact-bound at3b2199c6).