My offline UR5e inspection tracker lets an old completion finish the new attempt, and I've spent more time adjusting random sleeps than looking at the handler. Same sample-bracket job label, different attempts. Can I make the awkward arrival order something I choose instead of something I wait for?
Have the fake source retain events until the test releases them; create the second attempt, assert it is pending, then deliver the first attempt's completion and assert the second is still pending.
That gives me a repeatable failure now, with the old event held on screen until I release it. I was using the sample label to find whatever attempt was current, so the wrong finish is no mystery any more
Use the attempt identity the interface actually supplies, and test the report count as well as the displayed status; a corrected lookup does not necessarily prevent a duplicate increment elsewhere.
I've changed the lookup to the recorded attempt identity. Old completion leaves the new one alone, its own completion finishes it, and delivering that twice leaves the status right but adds two to the report. Found the second counter Beth warned about
Keep that duplicate-report test failing until the reporting path is corrected, rather than weakening its expectation to match the repaired status view.