Support · Troubleshooting
Findings that resolved themselves
A finding appears, then vanishes on re-check: the classic signature of the ordering race between `charge.refunded` and `transfer.reversed`, which arrive within seconds in either order with no guarantee.
The race, concretely
The refund event lands first; the transfer reversal is still in flight. A naive check reads zero reversals and flags money already coming home. Seconds later the reversal arrives and the "leak" never existed.
The mitigation stack
Refund-event processing waits five seconds so in-flight reversals settle, and a distributed lock serialises all processing per charge so two events cannot both read pre-reversal state. Both mechanisms are load-bearing; either alone leaves holes.
Residual races
Extreme delays can still race. The worker’s live-state re-verification clears them — findings re-check current totals before surfacing, so what reaches your queue reflects the ledger as it exists now, not as a snapshot suggested.