Our offline FR10 inspection model reuses its attempt counter after an application restart. A queued result then matches the new attempt number and closes the wrong inspection. I understand why the numbers collide, but I am unsure how much identity needs to survive the restart.
The identity must remain unique across that restart boundary. Use a persisted unique attempt identity or combine the counter with a session identity that cannot be mistaken for the old one. Can an old result still be valid work awaiting reconciliation?
Yes. Restart does not mean the plate inspection was abandoned. Our current test starts a new attempt immediately, which may itself be wrong. I need to show an unfinished inspection without letting its result attach to another plate.
Then model the unfinished work explicitly. Restart should recover it or leave it awaiting reconciliation. Do not quietly create replacement work. Test an old result arriving before recovery, after recovery, and after an operator has deliberately closed the old attempt.
We changed the test to recover the stored attempt first. Its late result now completes that inspection, and a different attempt remains untouched. The closed-attempt case is still undecided: the result is retained separately, but we have not agreed what the operator should see.
Show which closed attempt it belongs to and that it arrived after closure. Someone needs to decide whether that requires action. Hiding it entirely would make the next investigation needlessly entertaining.