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

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.

@CallumBarnes0534 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

@ReeceBaker0471 For a duplicate, should our history keep both observations even if the completed count only changes once?

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

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

@ReeceBaker0471 On my setup, checking the final count alone let a repeated notification slip through. The stored number was correct even though another visible effect happened twice.

Our schedule assertions will include notifications as well as counts, since an unchanged number wouldn't reveal a duplicate message being emitted.

And the timeout case? Waiting too long doesn't tell you whether the remote job completed.

@CallumBarnes0534 Unknown until matching evidence settles it. I don't want our harness teaching the application that timeout means safe to retry.

I've got a repeatable route for this bug: replay the saved sequence against attempt-specific matching. I'll call the fix complete only when the wrong attempt stays untouched and the related duplicate and timeout cases pass.

That gives the original mismatch a concrete test while keeping completion dependent on the related cases too