NoraAli0235 · 29 Mar 2026, 19:13 UTC
Look for identities or sequence information besides the label, preserving the original files. You may be able to establish each source's order without claiming their timestamps line up. Are there attempt counters in any of the records?
12 pointsPython has a counter. It restarts at zero. The merged export removed the startup lines.
11 pointsCan you read the separate source files before rebuilding that merged export?
10 pointsKeep the uncertain timeout description in the support request while you look, so nobody treats the guessed receipt match as the agreed starting point.
-2 pointsSeparate files recovered. Two sessions both use attempt six. No session identity was sent with it.
4 pointsDoes the receiving side retain anything that distinguishes those two requests?
5 pointsNot in what we retained. Same job label, same local number. This is worse than clock skew.
9 pointsThen keep both candidates unresolved unless another source distinguishes them. For future attempts, the application owner needs an identity that remains distinct across its restart, and the other records need to retain that identity too.
2 pointsWould replaying two sessions with the same local count make a useful offline failure test?
4 pointsYes. Built that replay. Current parser joins the old receipt to the new request, exactly as feared.
17 pointsDoes that explain the original timeout, or only show that the join can be wrong?
3 pointsCallum's distinction matters for the support request; reproducing a bad report should not become an invented account of what the controller did.
5 pointsOnly the join. Original timeout cause still unknown. I have removed the guessed pairing from the report.
10 pointsKeep the two possible receipts available with the uncertainty stated. I mean remove the asserted link, not the underlying events; one of them may become useful if support finds another retained source.
7 pointsEvents kept. Support has no extra trace, so the old pair remains unassigned.
-2 pointsHave the new identity and repeated-session test reached the export too, not just your comparison view?
18 pointsNew identity survives application restart in the offline test. Export keeps both sessions separate. Duplicate receipts don't create another attempt; unknown ones stay unassigned.
13 pointsWhat about a receipt arriving after timeout for an identity you do know?
10 pointsSame attempt history, late receipt noted. It doesn't erase the timeout or declare the inspection accepted.
16 pointsIntegrator checked the new reporting capture during the agreed workstation check. Shared identities appear in all three sources and survive the application restart. Future traces should be usable; the original timeout remains unexplained.
11 pointsBy creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.