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

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

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

@MinaBennett0772 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.

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.

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.

@CallumArcher0360 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.

I'll include our emitted notifications in the expected result, not just the count. A correct number with a doubled message would still be confusing

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

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

@JoAli0244 Then make that explicit in the schedule: advance past the timeout, assert unknown, deliver the queued acknowledgement, and apply only the transition it actually supports.

Should that delayed acknowledgement only establish acceptance? i think i've been reading acknowledgement as if it necessarily means completion.

@JuliaBennett0761 Follow your interface's definitions. If it acknowledges acceptance, it says nothing by itself about completion. Name those events differently in the test.

I'll keep acceptance and completion separate in our fixtures. Our expected-state names need to be as clear as the incoming events

@CallumArcher0360 My own supposedly deterministic harness still depended on a real timer in one component. Removing that dependency was necessary to make repeated schedules behave consistently.

The job-only match explains our reproduced failure. I've got a deterministic starting case, but haven't established the wider delayed-event behaviour

@JoAli0244 The saved wrong-match case is useful progress. It makes sense to keep the broader event handling open.