Our application crashed after submitting a coupon check and before saving the outcome. The local file still says pending, and startup would send it again. I have stopped using that helper. How should we distinguish never sent from sent with an unknown result before the covering shift touches this?
Retain the submitted attempt and mark its outcome unknown. Have the interface owner reconcile any durable controller-side or application evidence for that identity before deciding whether another inspection is needed. Pending alone is too vague for automatic resubmission.
The developer has split never submitted from submitted without a known outcome. We retained the original attempt identity. They found a saved receipt for it, but no result yet.
Can the person on shift identify the physical coupon that goes with that attempt, Carla? The software distinction helps, but it will not identify a loose sample by itself.
The coupon is labelled and retained separately. Its identity matches the attempt. Quality has not accepted it from the receipt, and the developer has made the missing-result reason visible.
Test startup with one definitely unsent record and one submitted-unknown record. Also reopen after a reviewed decision is saved, so the second startup does not recreate the uncertainty.
Those tests pass offline. Submitted-unknown stays held, and the recorded decision survives reopening. The original coupon is still awaiting its separate review because the result was not recovered.
Has the covering shift tried the new wording without the developer explaining it? I would like to hear whether unknown sounds different from rejected to them.
They understood unknown but thought the review button would run another check. We are changing that wording with the trainer. The revised helper is not back in use yet.