I need to fix startup on our UR5e fixture verifier. Pending means both never sent and sent with unknown result. Startup resends both. A crash can therefore repeat work the robot already did.
Separate known-unsubmitted work from uncertain attempts, and stop automatically resending the uncertain ones while you establish what evidence can reconcile them; who will own that decision at startup?
Maintenance with quality for uncertain results. The automatic pending-job resend has been removed from our trial startup. We are drafting distinct states.
Yes. We can stop after the send attempt but before the result write. Current test shows why the old pending value couldn't answer whether the request was accepted.
Keep the attempt identity with the evidence you do retain, so a later result can be matched without assuming that the newest pending record is its owner.
The revised offline states preserve uncertain attempts and don't resubmit them. Late and duplicate result tests are passing for identified attempts. Older records without enough evidence remain unresolved.
Our operator once moved a sample while the application was down, so I would have the recovery record include any authorised physical intervention rather than assuming the fixture still matches the last saved description.