I can make our offline FR5 fixture-check reporter accept an old completion as the result of a new attempt. It's for a sample inspection setup with a reference plate and recorded job events. Random sleeps make the failure annoyingly elusive. I want to choose the delivery order deliberately.
Could your test hold events in a queue until you explicitly release each one? Then you can start the new attempt, deliver the old completion and check the state immediately, without hoping a sleep lands at the right moment.
Yes. The fake already owns delivery; I was delaying inside it rather than letting the test release a named event. That seems an unnecessary complication now.
We distinguish the physical item from another attempt to process it in our changeover records. Does this reporter retain both, or is the plate name doing all the work?
Zara's distinction matters. I meant a named event in the test, but George also needs whatever correlation the real interface actually supplies. The fake shouldn't invent information the receiver will never get.
The plate name was effectively doing all the work. I've added explicit attempt identity to the application model, with the real event mapping left as an unresolved interface question.
Include the same completion delivered twice after a legitimate finish. Rejecting the old attempt should not hide a separate duplicate-counting problem for the current one.
Both schedules now reproduce reliably offline. Old-attempt completion leaves the new attempt waiting; a duplicate adds nothing. I'm not calling the real reporter fixed until we establish its correlation evidence.