I cannot safely resend everything our FR5 file calls pending

NadiaArcher0378 · 2026年6月18日 11:13 UTC

回复讨论

主帖中文翻译暂不可用,以下显示英文原文;回复保留原文。 查看英文原文

NA
NadiaArcher0378
I'm splitting pending because it currently means two quite different things. Our FR5 housing-inspection application crashed after sending work but before saving a result, and startup resends pending entries. The robot might have carried on. How should I represent that uncertainty without quietly declaring the housing inspected?

5 条回复

TH
TheoBrown0932

Give uncertain submission its own durable state. Do not resubmit it automatically. Define reconciliation using the job identity and whatever retained execution evidence the actual interface provides.

13分
NA
NadiaArcher0378

I've removed automatic resend for those entries. The awkward bit is our identifier: it identifies the housing, not an inspection attempt. Two attempts can therefore produce the same label in the file.

11分
TH
TheoBrown0932

Separate the physical housing identity from the attempt identity. Retain their relationship. Also define which component owns the decision that an uncertain attempt has been reconciled.

16分
NA
NadiaArcher0378

The software maintainer is drafting that decision with quality. We've added distinct attempt identities in the bench version, but old entries cannot acquire missing execution evidence by being renamed. Those are still held for review.

16分
TH
TheoBrown0932

Include crashes around each durable write in the bench tests. A clean restart alone will not exercise the interval that caused this ambiguity. The older held entries remain a separate disposition question.

15分

参与讨论

欢迎来到 Application Robot

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

忘记密码?

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