Our verification request was sent before the application crashed, but its result wasn't saved; startup would resend the pending row. How should I preserve that uncertainty while separating it from genuinely unsubmitted plate jobs?
Keep the automatic resend stopped for that uncertain group while you reconcile it with receiver-side evidence, because the file describes what your application saved, not necessarily everything the receiver did after the request arrived.
Automatic resubmission is disabled for the investigation. The pending file is retained; I have not converted its rows to unsent just because no result is present.
Is there an attempt identifier on both sides, separate from the part or job name? I'd want to know what can actually link a receiver result to that pending row before discussing retry behaviour.
For the new design, the software and receiver owners need a durable attempt identity and defined handling of repeated delivery; otherwise moving the save earlier just shifts the crash gap to another line.
Oliver, agreed. I'd ask the test to stop after receiver completion but before the local save as well as before any send. Those are different cases for the recovery screen, even if the current helper calls both pending.
The draft now distinguishes unsent, outcome unknown and confirmed result. The old rows are not automatically assigned to those new categories; controls and quality will review the evidence they actually have.
The operator view will show a review hold and the identified job, with the review owner named. That is drafted, not tested. This old plate attempt still has no established result.