Our offline UR5e fixture-check test accepts an old completion against a new attempt. I can provoke it with sleeps, but not reliably enough for a regression test. I want to control event order directly and inspect the state after each delivery, including duplicates. The reference housing is unchanged; the attempt is not.
Use an explicit event queue in the test and release each event when the test says so. Can you start the second attempt while keeping the first completion held back?
Would you also check the displayed accepted total at each step? I cannot advise on the callback, but a correct internal match could still leave the planning screen counting the same housing twice.
Maya, are we counting accepted housings or completed attempts there? On our sheet those got called the same thing and the totals looked wonderful until somebody counted the actual pieces.
I meant physical housings with an accepted disposition. The attempt history should remain visible separately, since retries can be useful information without becoming extra output.
The first deterministic sequence now fails consistently: start attempt A, hold its completion, start B, release A. B becomes complete. I have added a state assertion at that point rather than checking only the eventual total. Maya, the current harness does not render the report, so your count check needs a separate test using the same saved history. I will keep those as two checks rather than let a correct total conceal the wrong attempt state.
Yes, and include both expected and actual attempt states. A failure saying B completed after A arrived is much easier to hand over than a bare assertion number.
Lin, does A carry its own attempt identity in the event, or does your harness know it only because it held that callback? That changes what the real code can match later.
The captured event contains the attempt reference. Our matcher currently ignores it and uses the active job label. The harness is not inventing a field absent from the captured reply.
That gives the developer something specific to fix. Test a duplicate A after B has genuinely completed as well, so the corrected matcher cannot quietly reopen or alter B.
And that saved history can feed the report test. Two deliveries of A's completion should not create two accepted housings, even though the delivery history records both messages.
Unknown-reference events currently land in a generic error list. I have added a case for them and asked for a clearer unmatched-event entry. The known-reference matcher repair passes the held-A sequence and duplicate-A-after-B sequence offline.
Does closing and reopening the report rerun any completion handling? Ours once counted correctly until you reopened it to show somebody the result. Very efficient way to manufacture output without touching a part.
That's worth a regression too, Theo. Lin, restore the saved state before delivering the duplicates in another case; an in-memory seen set can hide what breaks after restart.
Queued those persistence cases. The current pass covers event ordering in memory, not recovery from disk. Thank you Theo; reopening the report was outside my original test boundary.