My UR5e inspection application crashed after sending a housing request but before saving its answer. Startup resends everything marked pending, including untouched jobs and possibly completed ones. What can I separate without guessing what the receiver did?
Anna's question needs an actual person, but they also need somewhere to leave it undecided. A supervisor choosing between resend and complete is still guessing if both buttons require evidence they haven't got.
I'd make a small offline copy with a housing that has definitely never reached the send step and another stopped after that step starts. Restart both. You want to see the first eligible for normal submission and the second held for reconciliation, without needing a robot to demonstrate the difference.
David, a send-step flag written afterwards leaves the same crash gap. The durable record has to capture the intent before the possible external effect, and a crash there still leaves uncertainty rather than proving delivery.
Yes, I was too loose about the boundary. I meant a persisted intent before calling out, not a note afterwards. The test should interrupt on both sides of that write as well as around submission and result storage; otherwise it can pass while keeping the original hole.
That default needs a test of its own. Include a state the current program doesn't recognise, not just the new hold state, so an older installation cannot silently reinterpret a newer file as work to send.
And keep the original file format version with the record. I'm not suggesting the software magically understand a future format; refusing to offer submission is a valid response when it cannot interpret the evidence it loaded.
Parser now refuses unknown states. Repeated reopen preserves the uncertain housing, and the unsent example stays separate. Receiver lookup still unconfirmed.