I'm testing our sample acceptance bookkeeping tracking offline for a setup using Universal Robots UR5e in a workshop fixture-checking station, 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.
@CalebAdams0145 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?
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.
@CalebAdams0145 Keep the duplicate in diagnostic history while making the completion update idempotent, so receiving it again doesn't alter the accepted result or count.
Idempotence means reapplying the message doesn't change the result again. Recording that it arrived is separate from repeating the completion or count update.