I've reproduced a nasty little result swap in our offline reporting test. Start an inspection, start a later attempt, then deliver the first one's delayed completion. The new attempt turns green. It did not produce that result.
Random sleeps only reproduce it sometimes, which makes the test a poor witness. I want a fixed event sequence that catches this every time and checks the old result hasn't simply been thrown away to make the screen behave.
Drive the events explicitly in the test. Start the first identified attempt, start the second, then deliver the first completion. Assert both attempt records after each step. No real sleeping needed to establish that order.
That fixed sequence fails reliably now. The event includes the first attempt identifier, but our handler attaches it to whichever attempt is current. The old attempt stays pending while the new one completes.
Good, you have the wrong behaviour pinned down. Deliver that same completion twice as well. A handler can use the right attempt and still add its result to the total twice.
Amy, it is present in both the event and saved input. We were ignoring it in favour of the screen's current selection. Felix, duplicate delivery also raises the completed total twice.
Then route by the recorded identity and reconcile repeated receipts against that attempt's result. Keep the display selection out of ownership. The operator may be looking at an entirely different attempt when a result arrives.
Oliver's case is useful. Also deliver an unknown attempt identifier and require an explicit unmatched state. Do not let a fallback quietly revive current selection as ownership.
The revised handler passes delayed and duplicate delivery for the two identified attempts. First completes, second stays pending, total rises once. We also added Oliver's selection change and the unknown-identity case; both exposed more assumptions in the display code.
It goes to an unmatched list with the original event identity and source information. It completes nothing. The display can show that list without assigning the event to the selected attempt.
Our maintainer ran it from the test instructions. Restart exposed an export path that counted receipts instead of reconciled attempts. We have corrected that path and added the stored records, screen and export to the same assertions.
Yes. First attempt keeps its result, second stays pending, duplicate receipt adds no completion, and the unmatched event remains available. Those assertions now survive restart in the offline suite.
The maintainer also ran the agreed read-only reporting comparison on the workstation with the retained event set. Stored attempt records, displayed count and export agree after restart. We closed this reconciliation bug; the random-delay test is no longer our only way to find it.
Worth the boring explicit sequence. Has the test instruction kept the deliberately wrong arrival order so it cannot become another normal-order happy path later?