Our file stayed pending after a crash between sending a fixture-verification request and saving its result. The FR5 may have continued. Startup resends pending entries, but that label also covers work never submitted. What evidence should separate those cases before we change recovery?
Treat the existing pending label as insufficient evidence for resending. Preserve the file and any controller or application records first. A missing result in your file does not establish that the request was never received.
And give the hold an owner on the screen. If all the new software does is stop resending silently, someone will eventually restart it repeatedly because they think the monitor is broken.
Does the retained result identify an attempt, or just the coupon? A reviewed retry of the same coupon needs to remain distinguishable from the first request before you can assign a late result.
Victor, only the coupon label in the older records. David, we have disabled that startup resend while we preserve and reconcile them. Ben, the screen now shows unresolved submission with the coupon and maintenance contact, rather than merely remaining on pending.
The coupon still needs a disposition owner while that software state is unresolved; withholding a resend is sensible, but it does not decide whether the physical coupon has been inspected or accepted.
Test the crash boundaries explicitly. Before a durable dispatch intention, after that intention but before the send, and after the send before any result is saved. The middle case may need to remain uncertain even if that particular test sent nothing. Do not design the recovery from what the test author secretly knows.
Niamh's middle case is easily missed. I mean the recovery code cannot know whether it died immediately before or after an unrecorded external action. A new name for pending does not bridge that gap; the interface and durable records need an agreed contract.
Separate old-record reconciliation from the new submission design. Callum could test a much better scheme and still have those earlier coupons unresolved. I'd want both visible in the maintenance handover so a software release doesn't quietly certify the old work.
Rachel, the hold is saved and survives reopening. Henry, quality owns the physical coupons and has not accepted the ambiguous ones. Laura, the proposed sender stops on an intention-save failure. New attempt identities are agreed for the software design; older coupon-only results remain unassigned where retries compete.
Has an intended shift user read that hold without your explanation? Would like to know whether they understand it isn't a failed inspection or permission to repeat one.
Adrian's two-track point belongs in the release note. Keep the old ambiguity even if all the new offline tests pass; otherwise you are repairing the history by optimism rather than evidence.
And do not let a later technical completion stand in for quality acceptance, even when the attempt link is unambiguous; those answer different questions.
Offline crash-boundary tests now preserve uncertainty and prevent dispatch when the intention cannot be saved. Reopen retains the hold. Isabel, the shift reader distinguished it from both rejection and a repeat instruction. The actual interface implementation still needs review, and quality is retaining the unresolved older coupons separately.