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

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

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

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

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

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.

What state do you expect after timeout? The local wait ending doesn't establish the remote job's final outcome.

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

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

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

@LinAbbott0009 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 use distinct acceptance and completion events, with equally explicit expected states, so our fixtures don't blur the distinction we're trying to test.