Skip to content

chore: re-pin the thousandeyes corpus document to 7.0.100 - #92

Merged
ShocOne merged 1 commit into
mainfrom
chore/repin-corpus-document
Aug 14, 2026
Merged

chore: re-pin the thousandeyes corpus document to 7.0.100#92
ShocOne merged 1 commit into
mainfrom
chore/repin-corpus-document

Conversation

@ShocOne

@ShocOne ShocOne commented Aug 14, 2026

Copy link
Copy Markdown
Member

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:

the pinned thousandeyes document is not what
https://pubhub.devnetcloud.com/media/000-v7-apis/docs/reference/unified-oas/api.yaml served.

main was green at 12:58 today and red from 14:01. Confirmed by fetching and
hashing directly:

served:  68e45bf31813e6115b060bf14a720ee017dc00103e963cc552813958d1d8b82d   version: 7.0.100
pinned:  664dffebf5db224e5414f1444e083d39bd4a201813e6c187b07d9b527f030b67   version: 7.0.99

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

pinned now
version 7.0.99 7.0.100
sha256 664dffeb… 68e45bf3…
paths 205 207
operations 323 326

corpus.lock.json says a change here "changes what several tests mean, so it is
reviewed, 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.RewriteLock rather than by hand, so the
hash, counts and timestamp are the toolkit's own measurements.

A gap this surfaced

corpus.Describer is never installed. Its doc comment says "The CLI
installs the real parser", and nothing in internal/ or cmd/ assigns it — I
grepped the whole tree. The default returns "unparsed", 0, 0, so a re-pin run
as the code stands today writes:

"operationCount": 0,
"pathCount": 0,
"version": "unparsed",

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 RewriteLock at all; it has no caller outside its own tests.

Worth fixing properly (a corpus verb, or installing the describer where the
comment 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 — empty
  • scripts/repo_hygiene_gate.sh — pass
  • go build ./... && go vet ./... — pass
  • go test ./...whole suite green, including both
    TestIntegration_*_APinnedVendorDocument

🤖 Generated with Claude Code

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>
@ShocOne
ShocOne merged commit 20ab404 into main Aug 14, 2026
2 checks passed
@ShocOne
ShocOne deleted the chore/repin-corpus-document branch August 14, 2026 15:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant