fix: tolerate a missing binary snapshot data file#914
Merged
Conversation
…iko#911) End-to-end functional test: a binary snapshot whose data file is gitignored by extension is absent on a fresh checkout while its `.snap` metadata stays tracked. Accepting a new value then fails with `No such file or directory (os error 2)`. Fails on master; the accompanying fix makes it pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…tsuhiko#911) SnapshotContents::Binary now holds Option<Rc<Vec<u8>>>; a missing data file loads as None instead of aborting, fixing the accept crash and the misleading runtime warning when binary data files are gitignored. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Thank you! |
Merged
max-sixty
added a commit
that referenced
this pull request
Jun 11, 2026
Minor release. Highlights since 1.47.2: - `strip_ansi_escape_codes` setting (#899, @pierluigilenoci) - Opt-in YAML literal blocks for multiline metadata strings via `INSTA_YAML_BLOCK_STYLE=1` (#851, @ivov) - An explicit `--accept` now overrides `CI=true` (#924) - `cargo insta test --profile` now translates to nextest's `--cargo-profile`; new `--nextest-profile` flag (#910) - Windows `--snapshot` path fix and partial-path filter matching (#904) - Accepting a binary snapshot tolerates a missing data file (#914) > _This was written by Claude Code on behalf of @max-sixty_ Co-authored-by: Claude Fable 5 <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.
cargo insta accept(andcargo insta test --accept) fails with a nonspecificNo such file or directory (os error 2)and refuses to accept whenever a tracked.snapbinary snapshot's data file is absent, even with--include-ignored. That absence is the normal state after checking out a project that gitignores its binary data files: the.snapmetadata is committed but the data files are not, so they're missing on any fresh clone, on CI, or aftergit clean. This is the setup reported in #911.The cause isn't the ignore walker, which is why
--include-ignoreddoesn't help. When a snapshot is loaded,Snapshot::from_fileeagerlyfs::reads the binary sidecar, and a missing sidecar makes that?abort the whole load. Butcargo-instaonly needs the old snapshot's metadata here (it never reads the old binary's bytes, only the extension, to clean up a stale file), and insta's own runtime already tolerates a missing old snapshot duringcargo insta test. So the abort was an inconsistency, and one you couldn't recover from with the obviousaccept.This makes an absent payload a first-class state.
SnapshotContents::Binarynow holdsOption<Rc<Vec<u8>>>;from_filemaps aNotFounddata file toNoneinstead of erroring (a present-but-unreadable file still errors). A freshly produced snapshot always carriesSome. This fixes both theacceptcrash and the misleadingFailed to parse snapshot filewarning the runtime printed in the same scenario.Note: this changes the shape of the public
SnapshotContents::Binaryvariant. No call site in either crate binds the payload directly (all match via_,{ .. }, orunreachable!()), so nothing else needed touching, but it's a public-type change worth a semver note.Includes a functional test (
test_binary_accept_missing_old_binary) that reproduces the failure (tracked.snap, absent data file, thenaccept) and passes with the fix.Closes #911. Thanks to @Kinrany for the report.