Our old FR5 result ticks off the new inspection attempt

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.

Does the saved result contain the old attempt identifier too, or is that lost before the handler sees it?

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.

Can your test select a third attempt on the screen before delivering the first result, Nina?

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.

What does unknown identity do now? I would want the event retained for investigation, not lost as a parsing failure.

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.

Restart between receipt and reconciliation too. A tidy in-memory answer can still double-count when the process reloads a partly updated history.

And read the exported total in that test. Not just the screen that you've been fixing all week.

Has another person run the fixed sequence without your debugging setup beside them?

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.

Thanks for returning with the export finding. Did the original delayed result remain attached to its first attempt through that restart case?

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?