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

our fr10 incident export loses the one identifier I need

JuliaBrooks0848 · 2026年2月28日 18:41 UTC

回复讨论
JU
JuliaBrooks0848
I can see two bracket attempts under the same reused job name, with a restart between them. The exported acknowledgement has no attempt identity and the clocks disagree. The raw controller record has an extra sequence field the export dropped. Can I use that to recover the link, or am I dressing up another guess?

17 条回复

MA
MayaBarnes0562

Does that sequence field also appear on an identified request?

10
JU
JuliaBrooks0848

Yes, in the raw request record. I don't yet know its lifetime or whether it starts again after controller restart. Application restart definitely happened; controller restart isn't established.

21
SA
SamBrooks0855

Can the package author explain the field's scope and link both records within their source session? A matching number is useful only if it identifies the same exchange rather than being reused in another session.

20
IM
ImranAli0218

Retain the raw files before fixing the export.

15
FI
FionaAli0238

And give the bracket an explicit unresolved status while you investigate. We had a lovely incident timeline once, but the person at the bench only saw the last green result. The physical item and the software investigation need to stay connected.

19
JU
JuliaBrooks0848

Raw files retained, Imran. Bracket is held by quality, Fiona. Author confirms the field is scoped to the recorded controller session and is comparing the two request records with the acknowledgement.

6
MA
MayaBarnes0562

Is the session identity retained too?

6
JU
JuliaBrooks0848

It is. Same controller session across these records. Author matched the acknowledgement to the earlier request; later attempt has another sequence value. That link doesn't use the wall-clock ordering.

9
SA
SamBrooks0855

What does the matched acknowledgement mean in that package: request received or inspection completed? Recovering ownership still leaves the event's meaning to establish.

19
JU
JuliaBrooks0848

Receipt only. Our export labelled it complete, which is a second mistake. No inspection result recovered from that event, and quality's hold stays put.

13
IM
ImranAli0218

Good catch. Fix both omissions in the export.

23
FI
FionaAli0238

Please keep the receipt-versus-result example in the teaching notes too. Otherwise the next person can follow the identifiers perfectly and still tell the operator that a bracket passed when all they found was a received request.

14
SA
SamBrooks0855

Will the revised recorder include application attempt identity as well as the controller's scoped exchange reference? That should let the maintainer follow the relationship without reconstructing it from raw files every time.

19
JU
JuliaBrooks0848

Yes. Revised export preserves both references, source session and actual event meaning. Controlled replay of the two requests, restart and delayed receipt now shows the earlier request received and the later one still without receipt.

0
MA
MayaBarnes0562

Does the display still call the old receipt complete?

17
JU
JuliaBrooks0848

No. Display corrected alongside export. Maintainer reproduced the captured sequence through the normal reporting path; both agree. Quality has since issued the bracket's disposition from its own review, not from this receipt.

19
FI
FionaAli0238

Thanks for returning with the event meaning as well as the matching number. That's a useful resolved investigation: you found which request received an answer without turning that answer into an inspection result.

19

参与讨论

欢迎来到 Application Robot

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

忘记密码?

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