Our handler matches only the job label. The saved sequence reliably shows the earlier completion arriving after a new attempt begins and being attached to that new attempt.

@NaomiBennett0767 Use the saved sequence to exercise matching by attempt identity, with a controllable harness clock. Making the ordering deterministic should cover this race condition.

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

You're right; my coverage claim was too broad. This schedule targets the reproduced mismatch, and the duplicate and post-timeout acknowledgement cases need their own schedules.

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

Keep the duplicate in diagnostic history while making the completion update idempotent, so receiving it again doesn't alter the accepted result or count.

@JackBrooks0863 Is idempotent just another word for ignoring the second message? I'm not sure how that fits with retaining it in the history.

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

My offline test used to assert only the final count. It missed a duplicate notification because the number happened to stay right.

@SamAli0246 I've isolated the incorrect job-label match in a saved sequence. The remaining duplicate and delayed-event behaviour still needs establishing.

@NaomiBennett0767 That's a clear partial result: an isolated identity mistake, with the other delivery cases still unverified.