ChrisBlair · 18 Oct 2025, 20:17 UTC
Hold the old event in a queue. Release it deliberately after the new attempt starts.
20 pointsWe have a fake event source already, just no hold control; I'll ask the developer to add explicit release rather than another delay setting.
11 pointsAssert the new attempt stays pending at that exact point.
2 pointsDoes the old event carry an attempt identity, or is the display matching only the reused plate job label?
-5 pointsThe event has an attempt reference, Kai, but our handler matches the plate label; that is why the late result finds the newly opened row.
5 pointsAlso send it twice. Matching and duplicate counting can fail separately.
6 pointsThen send the genuine new result. Rejecting everything must not pass the test.
11 pointsKeep the stored result and displayed state as separate assertions, so the test can show which one changes incorrectly.
16 pointsThe queued sequence now fails reliably on the old handler, with display and stored-row failures shown separately; the replacement handler is not finished, but at least I can demonstrate the problem without narrating excuses for the timing.
18 pointsWho keeps that test with the handover?
1 pointsThe developer will include it with the maintained test set, and I will use the same sequence in the tutor notes; restart identity rules still need their own case, so this isn't the whole recovery test.
21 pointsThis discussion is closed to new replies after six months without activity. Last activity: .