The Property Lookup That Silently Returned "Not Found"

# The Property Lookup That Silently Returned "Not Found" A client asked me to explain why a data-matching feature was quietly useless for most of their users. Nobody had filed a bug. The feature just didn't work for the majority of lookups, and the team had started to believe the underlying dataset was simply incomplete. ## The cap that never announced itself The lookup pulled a reference dataset into memory and scanned it linearly for a match — a reasonable design when the dataset was small, in a beta, in a demo. Nobody revisited it as the dataset grew, and nobody had to, because the code never threw an error. Past a certain row count, the in-memory structure the lookup relied on simply stopped including everything, and matches beyond that boundary returned the same result as a genuine miss: not found. There was no distinction in the response between "we checked and it isn't there" and "we stopped checking before we got to it." That's the shape of bug that survives audits: it doesn't crash, doesn't log an error, doesn't show up in a stack trace. It just quietly returns the wrong true-looking answer, and the only way anyone notices is by independently knowing what the right answer should have been. ## Measuring the actual miss rate, not trusting the absence of complaints The fix started with measurement, not code. I pulled a sample of records that should have matched under the dataset's own logic and ran them through the live lookup to see how many actually resolved. The number was close to zero. After raising the cap and switching to a structure that didn't have one, the same sample resolved almost completely — the remaining handful were genuine data gaps, not code defects. That gap — between "the feature appears to run without error" and "the feature is silently wrong for most inputs" — is the exact thing a code review misses and a live-data test catches immediately. Nobody diligencing this codebase from the outside would have found it by reading the matching function; the function looks correct. You'd only find it by picking real inputs you independently know the answer to and checking whether the system agrees with you. ## What this changes about how I evaluate matching logic I no longer accept "the lookup works" as a claim I can verify by reading the implementation. Any matching, dedup, or reconciliation logic against a dataset that could plausibly grow past whatever structure holds it in memory gets the same treatment: pull known-good inputs, run them live, and compare. It costs an afternoon. The alternative is a feature that looks shipped, passes every manual smoke test a developer would think to run, and fails silently for the majority of the population it was built to serve — the worst kind of bug, because it never generates a signal that tells anyone to go look for it.