Skip to content

go test served a cached pass against a corrupted parity corpus - #105

Merged
brentrager merged 1 commit into
mainfrom
fix/go-test-cache
Aug 20, 2026
Merged

go test served a cached pass against a corrupted parity corpus#105
brentrager merged 1 commit into
mainfrom
fix/go-test-cache

Conversation

@brentrager

Copy link
Copy Markdown
Contributor

Reproduced on main, not taken on faith

The Go lane loads parity/sampling-corpus.json and parity/pii-corpus.json from outside its package directory. Go's test cache does not treat such a file as a package input, so editing it does not invalidate the cache:

$ go test ./...            -> ok  github.com/SmooAI/observability/go  3.5s
$ <corrupt one corpus hash vector>
$ go test ./...            -> ok  github.com/SmooAI/observability/go  (cached)
$ go test -count=1 ./...   -> FAIL  FNV1a32("") = 2166136261, want 12345

A green Go lane on a corpus-only change could therefore mean nothing ran — the exact failure the corpora exist to prevent, in the one language whose cache can hide it. CI is not immune: actions/setup-go restores GOCACHE, which includes the test cache.

Fix

-count=1 on both go test invocations — the PR lane and the publish gate.

Scope check on the other four

Go was the only one. Cargo has no test-result cache; .NET and TypeScript have none; pytest's is opt-in and not enabled here.

What this does and does not invalidate

It does not invalidate #95's negative controls — those edited sampling.go, a package source file, which invalidates the cache correctly, and each one did go red.

It does invalidate the weaker claim that a green Go lane proves the current corpus was read. That claim is now true.

Closes th-062793 for this repo.

🤖 Generated with Claude Code

https://claude.ai/code/session_0152bbE1veqfG1SVJdyLCBxC

@changeset-bot

changeset-bot Bot commented Aug 20, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 119df81

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

The Go lane loads parity/sampling-corpus.json and parity/pii-corpus.json from
OUTSIDE its package directory. Go's test cache does not treat such a file as a
package input, so editing it does not invalidate the cache.

Reproduced on main, not taken on faith:

    $ go test ./...            -> ok  github.com/SmooAI/observability/go  3.5s
    $ <corrupt a corpus hash vector>
    $ go test ./...            -> ok  github.com/SmooAI/observability/go  (cached)
    $ go test -count=1 ./...   -> FAIL  FNV1a32("") = 2166136261, want 12345

So a green Go lane on a corpus-only change could mean nothing was run. That is
the exact failure the corpora exist to prevent, in the one language whose cache
can hide it — `actions/setup-go` restores GOCACHE, which includes the test
cache, so CI is not immune.

`-count=1` on both `go test` invocations (pr-checks and the publish gate).

Scope check on the other four: Rust reads the corpus via include-free
std::fs at runtime but cargo has no test-result cache, .NET and TS have none,
and pytest's is opt-in and not enabled. Go was the only one.

This does NOT invalidate #95's negative controls — those edited sampling.go, a
package source file, which invalidates correctly. What it invalidates is the
weaker claim that a green Go lane proves the CURRENT corpus was read.

Closes th-062793 for this repo.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0152bbE1veqfG1SVJdyLCBxC
@brentrager
brentrager merged commit c4fe2e9 into main Aug 20, 2026
8 checks passed
@brentrager
brentrager deleted the fix/go-test-cache branch August 20, 2026 19:13
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