Our earlier delayed-result tests taught me not to let one attempt finish another. I've found a separate hole in this startup helper: pending means both never sent and sent with no saved result. It resubmits both after a crash. I've stopped that path in the test build, but what should recovery know before retrying the uncertain bracket check?
Cannot let the FR10 startup helper retry every pending entry
TheoBarnes0584 · 2025年10月12日 00:47 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
4 条回复
Its original attempt identity and whatever the receiving side retained about it. Don't manufacture a fresh identity just because the file lacks a result. You could give an already completed inspection a convincing new label.
5分We save the attempt ID before sending, so that part survives. But the helper creates a new one for every retry. The fix needs to query or reconcile the old attempt, not jump straight to another request.
18分Yes. And if the old outcome cannot be established, leave it unknown for an authorised decision. Don't let a failed query become your evidence that the original inspection never happened.
4分Did you include a crash after the receiver completed but before your local save? Interested whether the revised startup presents that as uncertain rather than quietly adding it to the work queue again.
12分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .