Why an applied finding came back open
The unique index only covered open and acknowledged. The night after apply, the scan inserted a second open row and un-made the decision.
Published 2026-09-10 · Search job: supply audit applied finding duplicate
The first time we applied a Supply Audit exclusion, the next nightly scan inserted a second brand-new open row for the same exchange and reported "+1 new finding." The buyer decision had been silently un-made.
The unique index that was supposed to protect a live entity only covered open and acknowledged. The update-then-insert in persistFindings matched the same short list. The moment a row left those two states, dedupe stopped protecting it. applied became a costume.
What we changed
The update now matches open, acknowledged, applied, and dismissed. expired stays out of that list on purpose. Expiry means the entity stopped tripping. A later trip is genuinely new.
applied still does not mean the waste stopped. Apply creates targeting and never touches live delivery. The flagged exchange keeps appearing for the whole lookback window, and indefinitely if no campaign is pointed at the new targeting. That is why the applied row's metrics are refreshed rather than frozen.
dismissed findings also refresh metrics. They do not auto-reopen just because spend grew. That is a known limit, not a hidden feature.
Why this note exists
A dashboard that says "applied" while the next morning says "new finding" trains people to ignore both words. The same class of mistake as reporting that doubled spend: two writes that look like two facts.
Apply a Supply Audit finding is the job page. Point the next campaign at the returned targeting id, or the lookback will keep lighting up.