I was asked which inspection attempt timed out, and our report gives me the same job label twice. The application restarted between them. Python, PLC and controller logs have different clock readings, so lining up the nearest times produces a very neat answer that I do not trust. We have one acknowledgement which could belong to either attempt.
Is there anything besides the job label that survives through the request and acknowledgement, such as an attempt identifier or controller sequence value?
Application logs have a local counter, but it resets on restart and was not sent with the request. Controller log has its own sequence. Nobody has mapped that back yet.
Please leave an unmatched row unmatched. I've seen 'nearest time' quietly turn into 'confirmed cause' by the time the same spreadsheet reaches the incident meeting.
Application adds the current job label. The reply itself does not contain it. That makes the labelled acknowledgement row much less useful than I thought.
Who uses that report to decide whether a plate needs another inspection? I'd want them told about this before they treat the second labelled row as a second completed attempt.
And who is collecting the controller log? If it's somebody outside your team, give them the restart interval as well as the job name so they don't send only one attempt.
One request is linked by a retained transport trace. The later acknowledgement still cannot be assigned. Harish, quality has been told not to use these rows as inspection completion evidence. Noah, controls supplied the interval spanning both attempts.
For the repair, carry a restart-safe attempt identity through the exchange where the interface permits it. If it can't echo identity, the design needs another explicit correlation mechanism.
And don't solve it by making the timestamps prettier. Clock checks help investigation, but delayed replies can still arrive while a different attempt is current.
Controls and the application owner are reviewing an interface change with an echoed attempt identity. We will test delayed replies after a restart as well as normal completion. The old incident remains partly unknown.
Include duplicate and out-of-order replies in those tests too. A unique label is useful only if the receiver checks it before changing the attempt state.
Noah, quality reconciled the plate separately and retained that decision with the incident. Harish, the proposed report gives unmatched replies their own reason field. Alex, those tests are included. We have not deployed the interface change yet; at least the old report no longer claims two known results.