I thought I had a simple timeout to explain. Then I put the Python log beside the PLC trace and controller events. Their times disagree, and the application reused the same job label after restarting.
There is one acknowledgement near the timeout in the sorted view. It might belong to the earlier attempt. I don't want to build a confident story from the sort order just because it looks tidy. Has anyone found a useful first comparison when the original events are still available but the labels are this poor?
Preserve the original order within each source and split the application sessions first, because one reused label should not make two attempts look like one long attempt.
The restart marker separates them clearly in the raw application file. Our merged report removed that marker. I've put the two sessions into separate columns beside the untouched PLC and controller files.
Record the clock settings and any known uncertainty before aligning those columns; changing today's clocks will not retrospectively establish the order of the old events.
Julia, the raw acknowledgement contains a sender session value that the report drops. Leah, the controller export uses a different time basis; the maintainer is documenting that before we compare times.
Can that sender session be linked to either application attempt independently of the timestamps? I would use it only if its meaning and lifetime are known, not because it happens to look like the earlier session value.
Theo's right about the meaning. We fixed a display and export together on another job because the pretty view had hidden the identifier; fixing just Amanda's spreadsheet would leave the next person with the same trap.
The application author confirms the field is the sender's session identity, and the saved start exchange links it to the first attempt. The acknowledgement belongs there. The second attempt has no matching acknowledgement in these records.
A queued delivery survived the first application's disconnect. The developer reproduced that offline and fixed the report to retain session and attempt identity. The new test delivers the older acknowledgement while the newer attempt waits; it stays with the first attempt.
Does the newer attempt's own acknowledgement still appear correctly after that delayed one? The test needs to show you have not simply ignored everything arriving after a reconnect.