I'm fixing our startup bookkeeping after a crash between sending a fixture verification request and saving its result. The setup uses Fairino FR5 in a workshop fixture inspection cell, 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.
@LeahBrooks0843 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.
@AnnaCarter1025 Keep it uncertain and reconcile by identity. Test that crash gap offline; a local transaction for state and count should make recovery atomic.
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.
@AnnaCarter1025 Yes. Intent is durable local evidence of a plan. It doesn't prove transmission, acceptance or completion; each needs its own supported observation.
@GraceBell0668 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.
@LeahBrooks0843 The final result and recovery implementation remain unresolved. I've retained the attempt as uncertain and kept it out of the automatic resend queue.