Just the job label. I've saved the sequence: earlier completion arrives after the new attempt starts. It reproduces the wrong match.

Replay that sequence with explicit attempt matching. Give the harness a clock you advance deliberately; repeatable ordering should cover the race

It covers that order, not every race. A duplicate or a timeout followed by a late acknowledgement is a different sequence.

Fair. I meant this reproduced wrong match, not the whole class. Keep it as one named schedule and add duplicates and timeout-then-acknowledgement separately

@CarlaBarnes0575 How should I handle history when the same completion is delivered twice? I'd expect one count change but still want both observations visible.

Yes. Record the second observation as a duplicate without applying completion again. You want repeat delivery to leave the accepted result unchanged

@CarlaBarnes0575 Idempotent means ignoring it, basically? Or am I missing why you'd log something you ignored?

Same effect when applied again. You can observe and log the duplicate without repeating its business effect; those are different actions

Right, keeping evidence of the duplicate rather than pretending it never arrived. Thanks, that distinction helps.

What will your offline test do if two messages have the same attempt identity but different results? I would keep that separate from the identical duplicate case. Otherwise the word duplicate could hide the very disagreement you need to investigate.

That case is not in my saved schedule. I was using duplicate to mean identical content, without saying so. I will add a separate conflicting-result example and leave its required handling as a question for the application owner. I do not want my test to bless whichever message happens to arrive first.

Keep both inputs in that example so the person deciding the policy can actually see the conflict.