chore: re-pin the thousandeyes corpus document to 7.0.100 - #92
Merged
Conversation
The vendor replaced the document the lock pinned, so the fetch no longer matched its hash and every test reading it failed. The pin now names what the URL serves. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
Why
ThousandEyes replaced the document the lock pinned. The corpus is fetched, not
vendored, so the fetch stopped matching its hash and every test reading it
failed:
mainwas green at 12:58 today and red from 14:01. Confirmed by fetching andhashing directly:
Local runs kept passing off the on-disk cache, which is exactly the case the
cache is keyed by content for — it only invalidates on a lock change.
What changed
664dffeb…68e45bf3…corpus.lock.jsonsays a change here "changes what several tests mean, so it isreviewed, not applied" — this is that review. The vendor added 2 paths and 3
operations; nothing was removed, and both integration tests pass against the new
document unchanged.
The lock was rewritten through
corpus.RewriteLockrather than by hand, so thehash, counts and timestamp are the toolkit's own measurements.
A gap this surfaced
corpus.Describeris never installed. Its doc comment says "The CLIinstalls the real parser", and nothing in
internal/orcmd/assigns it — Igrepped the whole tree. The default returns
"unparsed", 0, 0, so a re-pin runas the code stands today writes:
which is what my first attempt produced. I installed the real parser in a
throwaway harness to get the numbers above, so this PR's lock is correct — but
the next person to re-pin will hit the same thing. There is also no verb that
calls
RewriteLockat all; it has no caller outside its own tests.Worth fixing properly (a
corpusverb, or installing the describer where thecomment says). Not folded in here: this PR needs to be reviewable as a pin
change and nothing else. Happy to do it next.
Gates
gofmt -l internal cmd— emptyscripts/repo_hygiene_gate.sh— passgo build ./... && go vet ./...— passgo test ./...— whole suite green, including bothTestIntegration_*_APinnedVendorDocument🤖 Generated with Claude Code