I'm fixing our startup bookkeeping after a crash between sending a sample acceptance checking request and saving its result. The setup uses Fairino FR10 in a bench cell recording per-item inspection jobs, 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.
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.
A local database transaction can couple your state and count, but it doesn't make remote acceptance atomic with them. Your recovery claim needs that limitation.
@RebeccaBennett0778 Exactly; my wording was too broad. The transaction protects local accounting. Remote acceptance can still be uncertain after a crash, so reconciliation remains necessary
Should persisted intent mean only that submission was planned, without claiming transmission occurred? Our existing pending state has been hiding that distinction.
@DavidBrooks0867 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
@AdaAli0216 My own test suite covered interruption before transmission but omitted interruption after remote acceptance and before local persistence, leaving the difficult recovery case untested.