Our developer showed me the offline FR10 inspection test and I could follow it until he added random delays. Then sometimes the old plate completion finished the new attempt and sometimes the test missed it. Same supposed test, different story.
I am helping agree what the demonstration must show, not writing the receiver. Can we specify the order of the two attempts and the late message directly, so I can tell whether the change has actually worked?
Yes, ask for a held message which the test releases at a named point. Start the old attempt, hold its completion, start the new attempt, then deliver the held completion. You should be able to see both attempt identities without guessing from elapsed time.
That is much easier to follow. He can hold the message in the test sender. The receiver currently attaches a completion to whichever attempt is active, so there is no old attempt identity in its decision.
Then the receiver needs more than a repeatable test. Ask the controls owner what identity survives from the request through the completion. If the message cannot distinguish attempts, the receiver cannot recover that fact from arrival order.
Elliot, especially through a restart. I am dealing with an example where repeated values look useful until you ask how long they remain unique. Jonas, include that boundary in the identity discussion, even if your first demonstration stays simple.
The controlled demonstration now reproduces the fault every time. Useful, if slightly depressing. The proposed message change includes an attempt identity and a restart boundary, but the controls owner has not signed that off yet.
Keep the failing example. Once the identity handling is agreed, run that same order again, then repeat the current completion too. Rejecting the stale message should not mean counting the new one twice.