Make the expected pending attempt explicit before delivery. Otherwise the test can pass by ignoring every completion, including the valid one.

Does the real recorded event carry an attempt identity, or would your fake be giving the application information it never receives?

Recorded events have an attempt field. My handler was searching by job label. Fake events use the recorded shape.

Would two copies of the current completion also increment your finished count twice?

Good second case, Gabriel. Keep the delayed old message and the duplicate current message as separate named tests first. A long mixed sequence is harder to diagnose when it breaks.

Queue is in. Old completion reproduces the false finish every time. Duplicate current completion also increments twice. Two separate failures now.

That is useful progress. Check both stored status and displayed count after each delivery; fixing only the screen can leave the next launch wrong.

Handler now matches attempt identity and ignores a repeated completed transition. Old result leaves new pending; current result completes once; duplicate leaves count unchanged. Stored and displayed values agree.

What about an event whose attempt field is missing, rather than merely old?

And a restart between the two copies, since the duplicate memory might only live in the running process?

Missing identity now stays unassigned with a diagnostic entry. Restart test isn't written. I won't call duplicate handling complete across restarts yet.

I'd leave that restart case as its own open test, exactly as you have. The controlled queue solved the reproducibility problem, and your passing cases have a clear boundary instead of depending on how fast the machine happened to run.