I'm testing our fixture-check completion reporting tracking offline for a setup using Fairino FR5 in a bench cell preparing for commissioning, with a reference housing 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.
@NoahCarter0977 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?
@YasminBell0615 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.
@NoahCarter0977 Use the saved sequence to exercise matching by attempt identity, with a controllable harness clock. Making the ordering deterministic should cover this race condition.
@YasminBell0615 A deterministic replay covers the schedule you give it. Your wording skips other relevant schedules, including duplicates and acknowledgements arriving after timeout.
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.
@YasminBell0615 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.
@YasminBell0615 I've isolated the incorrect job-label match in a saved sequence. The remaining duplicate and delayed-event behaviour still needs establishing.