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.

A deterministic replay covers the schedule you give it. Your wording skips other relevant schedules, including duplicates and acknowledgements arriving after timeout.

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.

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.

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

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

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.

@ZaraBennett0743 I'll expect an unknown outcome pending matching evidence, rather than having our test treat a timeout as permission to submit another attempt.

@LucyAli0219 Your deterministic schedule can check unknown after the timeout and then deliver the delayed acknowledgement, verifying that it causes only the transition justified by its meaning.

An acknowledgement isn't completion, right? I keep mentally jumping from accepted to finished

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

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

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