fix(check): build-ref-check's refusal cannot be told from a stale clone #1273

Closed
opened 2026-09-06 11:10:27 +02:00 by bosun · 1 comment
Owner

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

her clone: 113 tags, missing v0.59.0
  go test ./...   ok=25  FAIL=3   TestBuildRefCheck_PassesACorrectlyBakedTag among them
  message: "9 of 9 absent from the tree"

after git fetch --tags (114 tags)
  main 26 ok / 0 FAIL · #1269 26/0 · #1240 24/0

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 main both 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

  • The refusal names the tag-resolution state it saw — tag count, or that the tag is absent locally — so a stale clone is distinguishable from a bad tree
  • It names the remedy (git fetch --tags) when the tag cannot be resolved
  • An arm exercises the unresolvable-tag path and asserts the message, not just the exit code

#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.

`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 ``` her clone: 113 tags, missing v0.59.0 go test ./... ok=25 FAIL=3 TestBuildRefCheck_PassesACorrectlyBakedTag among them message: "9 of 9 absent from the tree" after git fetch --tags (114 tags) main 26 ok / 0 FAIL · #1269 26/0 · #1240 24/0 ``` ## 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 `main` both 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 - [x] The refusal names the tag-resolution state it saw — tag count, or that the tag is absent locally — so a stale clone is distinguishable from a bad tree - [x] It names the remedy (`git fetch --tags`) when the tag cannot be resolved - [x] An arm exercises the unresolvable-tag path and asserts the message, not just the exit code ## Related `#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.
Author
Owner

CLOSED — #1291 merged at 3b2199c6. All three ACs verified against origin/main.

cmd/rt/build_ref_check.go:73    rev-parse --verify --quiet refs/tags/<ref>^{commit}   <- resolve FIRST
                        :113    "tag %s is absent from this local clone; run `git fetch --tags` and retry"
                        :114    COULD-NOT-GRADE, not FAIL
cmd/rt/build_ref_check_test.go:131  TestBuildRefCheck_MissingLocalTagNamesFetchRemedy
                              :146  asserts "tag v0.59.0 is absent from this local clone"
                              :149  asserts "git fetch --tags" in stdout
                              :152  and in the error

🔑 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 rc would 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:

A test that reads LIVE REPO STATE fails in a stale clone exactly as it would if the code were broken.

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 main both 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 at 3b2199c6).

✅ **CLOSED — `#1291` merged at `3b2199c6`. All three ACs verified against `origin/main`.** ``` cmd/rt/build_ref_check.go:73 rev-parse --verify --quiet refs/tags/<ref>^{commit} <- resolve FIRST :113 "tag %s is absent from this local clone; run `git fetch --tags` and retry" :114 COULD-NOT-GRADE, not FAIL cmd/rt/build_ref_check_test.go:131 TestBuildRefCheck_MissingLocalTagNamesFetchRemedy :146 asserts "tag v0.59.0 is absent from this local clone" :149 asserts "git fetch --tags" in stdout :152 and in the error ``` 🔑 **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 `rc` would 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:** > ***A test that reads LIVE REPO STATE fails in a stale clone exactly as it would if the code were broken.*** ✅ **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 `main` both 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 at `3b2199c6`).**
bosun closed this issue 2026-09-06 12:05:15 +02:00
Sign in to join this conversation.
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
frankenbit/release-toolkit#1273
No description provided.