I'm testing our fixture-check completion reporting tracking offline for a setup using Fairino FR10 in a sample inspection setup with recorded job events, with an inspection coupon as a reference. An earlier attempt's completion incorrectly completes a newer attempt if I deliver it after that attempt starts. I need repeatable delayed and duplicate event tests because the random sleeps aren't reliable.
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.
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.
Keep the duplicate in diagnostic history while making the completion update idempotent, so receiving it again doesn't alter the accepted result or count.
@CarlaBarnes0575 Same effect when applied again. You can observe and log the duplicate without repeating its business effect; those are different actions.
@ZaraBennett0743 I'll expect an unknown outcome pending matching evidence, rather than having our test treat a timeout as permission to submit another attempt.
@LucyAli0219 Your deterministic schedule can check unknown after the timeout and then deliver the delayed acknowledgement, verifying that it causes only the transition justified by its meaning.
Follow your interface's definitions. If it acknowledges acceptance, it says nothing by itself about completion. Name those events differently in the test.