Our offline reporter completes the newer attempt when an old coupon completion arrives after it starts. Random sleeps make the failure unreliable to reproduce. I need a controlled test of delayed and duplicate events that the maintainer can rerun, not another lucky failure on my laptop.
Control delivery explicitly through the actual handler: hold the old attempt's event, start the newer attempt, then deliver the held event and inspect both records. Repeat the same delivery to test duplication without relying on elapsed wall-clock time.
The saved event contains an attempt reference. Our handler ignores it and updates whichever attempt is active. That reproduces every time with explicit delivery, including when the older attempt already timed out.
Keep the old timeout as a terminal state unless your agreed model explicitly permits a reviewed change. A late event can be retained as evidence without turning timeout into success or completing the replacement attempt.
Does the test inspect the saved records as well as the screen, Anil? I've watched a display get fixed while the file underneath still told the next launch the wrong story.
Henry, only the event's recorded identity enters the handler. Isaac, assertions now cover both attempts in storage and the display. The proposed handler looks up the matching attempt and records late evidence separately from its terminal state.
Include an event for an unknown identity and a duplicate with conflicting contents, so the revised lookup cannot fall back to the active attempt or silently overwrite an already established result.
And verify the operator wording for that conflict. An unchanged green result with an invisible diagnostic warning would not explain why review is needed.
Tests pass for late, repeated, unknown and conflicting events. Unknowns are unassigned observations; conflicts raise a visible review state without replacing the stored result. The newer attempt stays pending until its own matching completion arrives.
Has reopening been included yet? Interested in whether the old event stays old after the process loses its in-memory list, especially if the attempt counter starts from the same value.
Reopen tests pass using the producer session and attempt counter already carried in the real event. The original handler fails our delayed-event case; the replacement preserves both histories across repeat delivery and restart. Maintainer ran the checked-in tests from a clean checkout.
That closes the bookkeeping defect demonstrated by this test. Keep the event-format reference with it; the offline result does not establish the physical inspection outcome or authorise retrying an uncertain real job.