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 · 12 Oct 2025, 00:47 UTC
4 replies
Replying to TheoBarnes0584
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.
5pointsReplying to RebeccaChan1126
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.
18pointsReplying to TheoBarnes0584
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.
4pointsReplying to TheoBarnes0584
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.
12pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .