In our offline test, delivering an old completion after a new attempt starts makes the new sample acceptance bookkeeping attempt look complete. The real setup uses Universal Robots UR5e in a sample inspection setup with recorded job events, with a sample bracket as a reference.
I'm trying to exercise delayed and duplicate events reliably; random sleeps keep making the test hard to reproduce.
Our handler matches only the job label. The saved sequence reliably shows the earlier completion arriving after a new attempt begins and being attached to that new attempt.
@LiamBaker0490 A deterministic replay covers the schedule you give it. Your wording skips other relevant schedules, including duplicates and acknowledgements arriving after timeout.
Fair. I meant this reproduced wrong match, not the whole class. Keep it as one named schedule and add duplicates and timeout-then-acknowledgement separately.
@FionaBrooks0847 Yes. Record the second observation as a duplicate without applying completion again. You want repeat delivery to leave the accepted result unchanged.
On my setup, checking the final count alone let a repeated notification slip through. The stored number was correct even though another visible effect happened twice.
Then make that explicit in the schedule: advance past the timeout, assert unknown, deliver the queued acknowledgement, and apply only the transition it actually supports.
Follow your interface's definitions. If it acknowledges acceptance, it says nothing by itself about completion. Name those events differently in the test.
Our handling of delayed events remains unresolved. Reproducing the identity mistake hasn't yet established that the corrected handler behaves reliably.