Our inspection application crashed after sending a coupon request but before saving its result. FR10 may have continued. Startup resubmits pending records, and pending currently means both never sent and outcome unknown. I need that distinction preserved for the next shift, not guessed from the file.
Hold those ambiguous records out of automatic resubmission. Then examine what evidence survives on each side: a durable request identity, an acknowledgement, a retained result. A job name and a pending flag won't tell you whether this particular coupon request ran.
What will the operator see while that investigation is waiting? I'd want the screen to say why the coupon is held and who can resolve it, rather than leaving a tempting retry button next to a vague pending label.
The startup resend is disabled for ambiguous work. The old record has the job name but no unique attempt identity, so I can't tie a retained controller result to this coupon request.
That physical link matters, but even a known coupon doesn't prove which attempt produced a result. Keep the request identity work and physical reconciliation together without letting either substitute for the other.
Coupon identity is retained, Pavel; attempt identity isn't. The unresolved case is held for the authorised review. Yasmin, the startup view now names that hold and the responsible role, with no automatic retry.
Who records the review decision if another shift takes over halfway through? I don't want someone to see a conversation note and mistake it for a completed reconciliation.
The review owner records the evidence and decision, separately from discussion notes. Our developers are adding durable attempt identity with the receiver owner, including what happens if the result save fails or a repeated request arrives.
Include restart after the reviewer records a decision, not only crashes during sending. I have seen a careful recovery procedure lose its conclusion because the application only remembered the decision until it closed. Your old uncertain case can remain uncertain while the new design is tested.
Offline checks now preserve the held state after failed saves and restarts, and preserve a recorded review decision. The old attempt remains unassigned. Receiver behaviour and the approved physical recovery still need joint verification before this returns to use.
Please return with that receiver check. The useful result will be what happens to the same identified request across restart, not merely that the new state names appear on the screen.