I want to use our plate-inspection replay in a maintenance lesson, but the old result only steals the next attempt on some runs. Random sleeps are doing the event ordering. A tutor cannot explain a failure that politely disappears when the class sits down. How would you make this a dependable test of the repair?
Use a queued sequence you advance deliberately. Old completion held back, new attempt started, old completion released. Then you can show exactly which row changes instead of asking the class to admire intermittent bad luck.
That suits the lesson. Our maintainer has a replay entry point already, but it currently reads everything at recorded speed. I'll ask for event-by-event release rather than another timing adjustment.
What should happen to the older attempt when its valid result eventually arrives? The test needs that answer as well as the requirement that the new attempt stays unchanged.
It does. Quality wants a valid late result reconciled to that attempt, with its history retained. They do not want it assigned to the current plate just because that is what the screen has selected.
Then have the expected result specify both attempt rows and the accepted-item total after each event. A corrected row assignment could still leave the count incrementing twice when a duplicate arrives.
The developer needs those assertions. The lesson can show the two rows and a plain explanation of why only one changes. I would not make operators read the whole test record.
Event-step replay is working now. It reproduces the wrong row change every time, and the proposed repair leaves the new attempt alone while updating the old one. Duplicate-count and restart cases are still being checked. Thank you Julia for separating the lesson view from the test record.