Two inspection attempts share a job number in our log

I have kept the original logs. Within the Python file, the timeout is before the restart. The pass arrives after it, but the job number is identical.

That establishes the application's recorded sequence, but a late reply from the earlier attempt could still have arrived after the restart.

Does the acknowledgement contain anything besides the reused job number?

An echoed attempt identifier would be useful; a local receive counter alone identifies the receipt, not necessarily the request that caused it.

Only the job number and result. There is a local counter, but it resets on startup. We have no evidence that distinguishes the two possible sources.

We found a similar ambiguity by reading the logs on paper before touching the code. Mark both possible histories; it stops the plausible one quietly becoming fact.

A table with source, local order and restart boundary helped us, because three timestamp columns had made our uncertainty look impressively precise.

For future attempts, discuss a persistent session identity plus a distinct attempt identity with the interface owner, and require the responder to echo the relevant identity.

The interface owner has proposed that change. I also asked what happens to late responses after a timeout. At present the screen will accept a matching job number without checking the attempt state.

That acceptance rule needs review alongside identification; uniquely labelling a stale response does not by itself stop the application using it.

We have recorded the old result as indeterminate. The proposed interface will reject responses outside the expected attempt state, but we have not tested that implementation yet.

Include delayed and repeated responses in those tests, particularly across a service restart; that is the boundary your original evidence could not resolve.