简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。

Why does every restarted FR5 inspection call itself the same job?

NoraAli0235 · 2026年3月29日 19:13 UTC

回复讨论
NO
NoraAli0235
My FR5 timeout has three disagreeing clocks and a reused job label. Everyone keeps choosing the nearest receipt. Nearest according to which clock? I need a match I can defend.

21 条回复

EL
ElenaBrown0949

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
NO
NoraAli0235

Python has a counter. It restarts at zero. The merged export removed the startup lines.

11
SA
SamBennett0768

Can you read the separate source files before rebuilding that merged export?

10
RE
ReeceBrown0906

Keep the uncertain timeout description in the support request while you look, so nobody treats the guessed receipt match as the agreed starting point.

-2
NO
NoraAli0235

Separate files recovered. Two sessions both use attempt six. No session identity was sent with it.

4
CA
CallumCarter0969

Does the receiving side retain anything that distinguishes those two requests?

5
NO
NoraAli0235

Not in what we retained. Same job label, same local number. This is worse than clock skew.

9
EL
ElenaBrown0949

Then 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
SA
SamBennett0768

Would replaying two sessions with the same local count make a useful offline failure test?

4
NO
NoraAli0235

Yes. Built that replay. Current parser joins the old receipt to the new request, exactly as feared.

17
CA
CallumCarter0969

Does that explain the original timeout, or only show that the join can be wrong?

3
RE
ReeceBrown0906

Callum's distinction matters for the support request; reproducing a bad report should not become an invented account of what the controller did.

5
NO
NoraAli0235

Only the join. Original timeout cause still unknown. I have removed the guessed pairing from the report.

10
EL
ElenaBrown0949

Keep 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
NO
NoraAli0235

Events kept. Support has no extra trace, so the old pair remains unassigned.

-2
SA
SamBennett0768

Have the new identity and repeated-session test reached the export too, not just your comparison view?

18
NO
NoraAli0235

New 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
CA
CallumCarter0969

What about a receipt arriving after timeout for an identity you do know?

10
NO
NoraAli0235

Same attempt history, late receipt noted. It doesn't erase the timeout or declare the inspection accepted.

16
NO
NoraAli0235

Integrator 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

参与讨论

欢迎来到 Application Robot

所有人都可以阅读论坛。登录或注册后即可发起讨论、回复或上传照片。

忘记密码?

注册账号即表示你同意我们的 使用条款 社区准则。请阅读我们的 隐私政策 ,了解我们如何处理你的信息。