I'm fixing our startup bookkeeping after a crash between sending a fixture verification request and saving its result.
The setup uses Fairino FR10 in a small production inspection area, with a reference plate.
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.
@AaronBaker0436 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.
@DavidBell0693 Keep it uncertain and reconcile by identity. Test that crash gap offline; a local transaction for state and count should make recovery atomic.
@AnikaAli0247 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.
Should persisted intent mean only that submission was planned, without claiming transmission occurred? Our existing pending state has been hiding that distinction.
@LucyCarter1002 The remote side may accept the request before the application persists its acknowledgement. Crashing between those events makes missing local acceptance insufficient to classify the attempt as 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.
@AnikaAli0247 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.