I'm fixing our startup bookkeeping after a crash between sending a part inspection request and saving its result. The setup uses Fairino FR5 in a workshop fixture inspection cell, with an inspection coupon.
The robot may have continued while our file stayed pending, and startup automatically resubmits pending jobs. That state currently covers both unsubmitted and uncertain work.
@PavelBrooks0788 I've found persisted submission intent and matching acceptance in the controller history, without a surviving completion record. This attempt is excluded from our automatic resend queue.
Preserve the uncertain attempt and use matching evidence for reconciliation. An offline crash replay plus a local transaction for state and count should provide atomic recovery
You're right to distinguish those. I meant atomic local accounting updates, not an atomic controller exchange; the acceptance gap still requires explicit uncertainty and reconciliation
Acceptance can happen before your local save. A crash in that gap leaves uncertainty, which is exactly why missing local acceptance can't mean unsubmitted
My own test suite covered interruption before transmission but omitted interruption after remote acceptance and before local persistence, leaving the difficult recovery case untested.
Our offline replay will interrupt between remote acceptance and local acknowledgement persistence, then verify that startup preserves uncertainty without issuing another request.
I'll require evidence of completion tied to the attempt before recording it as complete. The acceptance we've only establishes that it wasn't simply unsubmitted.
@CallumAdams0099 Attach the reconciliation source when you update the result. Preserve the interruption in history so the finished record still explains how you established it