A lookup that silently returns "not found": the difference between 0% and 82%

During a technical audit of an inherited property-risk platform, one defect turned out to be the highest-leverage fix. It also happened to be the kind of bug that's nearly invisible from the outside: nothing crashed, nothing logged an error, and the feature "worked" — it just quietly failed most of the time. ## The setup The application resolves user-facing risk data against a large geospatial parcel dataset — tens of thousands of individual property records. The lookup path that matches an incoming request to its corresponding parcel record had been built as an in-memory scan: load a batch of records, scan them, return the first hit or "not found." That's a reasonable pattern at small scale. It stops being reasonable the moment the dataset outgrows the batch size the loader was written against — and nothing in the code enforced that constraint, or warned when it was crossed. ## What "not found" was actually hiding The batch load was capped at 1,000 records. The real dataset had roughly 13,900. Any property whose record happened to fall outside that first 1,000-row window would silently fail to match — not with an error, not with a stack trace, but with the same valid-looking "not found" response a genuinely missing property would produce. There was no way, from the application's own behavior, to distinguish "this property really isn't in our data" from "this property is in our data, but past row 1,000." Sampling 12 properties from across the real dataset during the audit made the scale of the problem concrete: 0 of 12 resolved correctly before the fix. Not a fraction — zero. The lookup had drifted, unnoticed, into a state where it failed for essentially the entire address space beyond that arbitrary early slice — and every failure looked, to any API consumer, identical to a legitimate data gap. ## The fix, and its ceiling The fix itself was the boring part: replace the in-memory batch scan with a real indexed database lookup against the full table, so match correctness no longer depends on how many rows happened to get loaded first. After the change, the same 12-property sample resolved at roughly 82% — the remaining misses were genuine data gaps in the source dataset, not an artifact of the lookup logic. Going from 0% to 82% wasn't about finding more data — it was about the code actually looking at the data already there. ## Why this one is worth flagging in an audit, specifically The bug itself isn't the uncomfortable part — capped in-memory scans creep into codebases honestly, usually when a dataset was small enough for it not to matter. What's uncomfortable is how well this class of bug hides. A crash gets noticed. A slow query gets noticed. A silent, plausible-looking wrong answer does not — especially when "not found" is a normal, expected response for a real subset of inputs. There's no error budget to alert on, no exception to catch, because from the system's own point of view, nothing went wrong. That's exactly why this kind of defect belongs on a due-diligence checklist rather than waiting to be caught by a user complaint: any lookup path built as an in-memory scan against a dataset that has grown — or could grow — past its original assumptions deserves a direct check: pick real records from outside the window the original author was testing against, and verify they resolve. If they don't, and the failure is indistinguishable from a legitimate miss, you've likely found a bug that has been silently costing correctness for as long as the dataset has exceeded the cap.