During code review, a diff gives a SKU record value-based equality but leaves its hashing identity-based — why will a hash-set dedupe still emit duplicate SKUs?

## Why half a key type is worth zero Most environments give every object a default equality and a default hash that agree with each other: equality means "the same instance", and the hash is derived from the instance's identity. That inherited pair is internally consistent — and consistently useless for value semantics. The diff under review changes only one half: SKU records now compare equal when their product code, size and color match. But the hash still answers per-instance. The equality-hash contract — keys that compare equal must produce equal hashes — is now violated by every pair of distinct-but-equal instances in the system. ## Tracing the dedupe The catalog job builds a hash set to deduplicate SKUs merged from several supplier feeds. Two feeds deliver the same product as two separate record instances: 1. Insert record A: hash(A) routes to bucket 7; bucket empty; store A. 2. Insert record B, value-equal to A: hash(B) is identity-derived, routes to bucket 23; bucket empty; store B. The set consulted equality zero times. Both records survive, the "deduplicated" catalog carries phantom duplicates, and downstream systems see the same product twice. No error, no warning — the set behaved correctly given inconsistent answers from its key type. ## Why the tests are green This defect has a signature reason for escaping test suites: **identity hashing agrees with identity, and tests love reusing instances.** A test that inserts the same reference twice, or that asserts `a equals b` on two records without ever putting both into a hash-based container, exercises nothing the diff broke. The bug only fires when two *independently constructed* equal instances meet inside a hash-routed structure — exactly the production condition (two feeds, two deserializations) and exactly what a convenient unit test avoids. Green tests here prove consistency of the old identity pair, not correctness of the new value semantics. The test to demand in the same diff: construct two equal records through two separate code paths, insert both into a hash set, assert size one. A stronger companion is a property test over random field values asserting that equal records report equal hashes. ## The reviewer's rule, and its mirror image The operative review rule is mechanical: **a diff that touches equality or hashing must touch both, derive both from the same fields, and ship the two-instance container test.** Some ecosystems make the pairing hard to get wrong — compiler-generated value classes and record types derive both together — which is why reviewers push key types toward those forms. The mirror-image diff is worth recognizing too: value-based hashing over identity-based equality. Curiously, that one *honors* the letter of the contract — equal-by-identity objects trivially hash equal — yet the dedupe still fails, because the set defers the final verdict to equality, and identity equality never declares two distinct instances equal. The lesson generalizes: the contract is necessary, not sufficient. Correct behavior needs both halves expressing the *same* notion of sameness, not merely a non-contradictory pair. ## What to write in the review A useful comment names the mechanism, not just the rule: "Hash sets route by hash before comparing; with identity hashing, two equal SKUs never meet, so this dedupe is a no-op for cross-feed duplicates. Please add the value-based hash over the same fields and a test inserting two independently built equal records." That framing survives the author's likely rebuttal — "but equality is defined now" — because it explains why the equality code is unreachable for the case that matters.