Yes. The fake transport can store outgoing requests and let the test deliver responses explicitly. I have reproduced the failure with no sleeps: start one check, expire it, start the retry, deliver the first result. The retry becomes complete immediately.

Then assert the retry stays pending before delivering its own result.

We had a similar test that passed after adding IDs, then failed after a process restart because the counter started again. Distinguish attempts across the lifetime where old events can still arrive. Housing identity and attempt identity are doing different jobs here.

Does the response carry the attempt ID, or only the request?

Only the request did. I changed the fake responder and tracker to carry and compare an attempt token end to end. The old result now leaves the retry pending; its matching result completes it. We still need to agree that token with the real interface owner.

Have you delivered the matching result twice as well?

What happens if the pending attempt is cancelled before its matching result arrives?

The duplicate produces no second completion in the new test. Cancellation also stays final when its matching result arrives later. These pass in the offline tracker only; the restart case and production transport agreement are still outstanding.

Keep that explicit event delivery helper; it makes each ordering readable, and someone maintaining this later won't have to interpret a handful of mysterious sleep durations