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

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

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.

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

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

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

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

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

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.

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

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