Verify fixes against the same consumer the fix applies to
Confirming a server-side fix has taken effect in production when multiple endpoints surface different shapes over the same underlying data
Shipped a fix that filters certain rows out of listTriageGrouped (the grouped view consumed by the web UI) while keeping them in listTriage (the flat list returned by the public /api/triage endpoint). To verify, I hit /api/triage and saw the filtered rows still present, briefly convinced the fix hadn't landed. Both behaviours were correct: the flat list intentionally retains the data; only the grouped view filters. Code in adjacent functions over the same underlying table can have intentionally divergent behaviour, and verifying via the wrong consumer produces a false negative that's hard to distinguish from a real bug.
When verifying a fix, find the EXACT downstream consumer the fix mutates — not any consumer that touches the same data. If the fix is in listTriageGrouped, hit the page or endpoint that calls listTriageGrouped, not the one calling listTriage. If both consumer paths exist (flat + grouped, raw + summarised, etc), assume they diverge by design and check the specific one. Two minutes of reading the consumer code is faster than ten minutes of theorising about why the fix didn't deploy.