fix(tag-comparison): compare values per source file, not across the corpus - #436
Merged
Merged
Conversation
…orpus value_differences compared each side's corpus-wide canonical TagInfo (first file the extractor happened to visit), so a tag name recurring across files with legitimately different values -- Sony AFStatus* across camera bodies -- was reported as a same-file mismatch built from two unrelated files' real values. The engine now records every (file, value) instance and requires both sides' values to come from the SAME source file before reporting a value difference; keys that never co-occur on a file stay matched-by- presence, and empty instance maps preserve the old semantics exactly. 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
1 participant
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.
Summary
value_differencescompared each side's corpus-wide canonicalTagInfo— the first file the extractor happened to visit for thatfamily:namekey. A tag name that recurs across files with legitimately different per-file values (Sony'sAFStatus*binary-data tags across camera bodies) was therefore reported as a same-file mismatch built from two unrelated files' real values: A65 won oxidex's canonical slot, A580 won ExifTool's, and the report blamed A580 for a "wrong" value that was actually A65's correct one. The effect was batch-size dependent — it needed a corpus large enough to contain two cameras sharing tag names — which made it look like an in-process parser state leak.The engine now records every (file, value) instance (
ExtractionResult::all_instances,#[serde(default)]for cache compat) and requires both sides' values to come from the same source file before reporting a value difference. Keys that never co-occur on a file stay matched-by-presence. Empty instance maps reproduce the old canonical comparison exactly — pinned by the existing test suite through the now test-onlycomparewrapper.The state-leak hypothesis was tested directly and ruled out: isolated vs batched
read_metadataofSonyDSLR-A580.jpg(after 9 CLIE files in-process) produces identical AFStatus tags on current main.Salvaged from an interrupted session's worktree (base was 45 commits stale; rebased clean onto current main).
Test plan
cargo test --bin tag-comparison --features tag-comparison-binary— 71 passedcargo clippy --features tag-comparison-binary --bin tag-comparison -- -D warnings— clean🤖 Generated with Claude Code