I'm testing our fixture-check completion reporting tracking offline for a setup using Fairino FR5 in a PLC-coordinated inspection cell, with a sample bracket 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.
@NaomiBennett0767 Can you preserve that failing delivery sequence and check which identifier the handler uses to match completion: the specific attempt or only the job label?
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.
@NaomiBennett0767 Use the saved sequence to exercise matching by attempt identity, with a controllable harness clock. Making the ordering deterministic should cover this race condition.
You're right; my coverage claim was too broad. This schedule targets the reproduced mismatch, and the duplicate and post-timeout acknowledgement cases need their own schedules.
@JackBrooks0863 How should I handle history when the same completion is delivered twice? I'd expect one count change but still want both observations visible.
Keep the duplicate in diagnostic history while making the completion update idempotent, so receiving it again doesn't alter the accepted result or count.
@SamAli0246 I've isolated the incorrect job-label match in a saved sequence. The remaining duplicate and delayed-event behaviour still needs establishing.