Offline tracker gives an old completion to the newer attempt. Random sleeps won't reproduce it reliably. How should I control delayed and duplicate events?
Can the test inject a chosen event at a chosen state transition? Start the first attempt, retain its completion, start the next through the permitted test sequence, then deliver the old event while the new attempt remains pending. Assert both states before proceeding. That is a defined ordering, not a race you hope to win by sleeping longer.
Priya's question protects the test from inventing a better interface than the real one. If the identity is absent or ambiguous, the expected behaviour should preserve that uncertainty rather than let the test helper assign it using knowledge the application cannot have.
Jack, has the deterministic sequence reproduced the original failure now? Interested in that before the duplicate and restart cases make the test harder to read.
Now deliver a matched completion twice and check the report as well as the attempt state. Also deliver the old result after the newer attempt legitimately finishes. A state machine can look correct while a summary counter still treats every delivered event as another completed coupon.
Duplicate replay leaves the attempt unchanged but increments the report twice. Separate reporting defect confirmed. Restart persistence still untested.
Worth finding. Keep the two reproduced failures separate so the reporting fix cannot hide a tracker regression. You have a useful test sequence, not a completed reconciliation fix yet.