Our FR10 startup helper retries an inspection whose result may already exist

Our programmer found the request identity in the application log, and the inspection side has a result carrying that identity; the local pending row simply never received it.

Can the existing result be reconciled without sending another request?

Test that offline with the result held back until after restart. We had a recovery demonstration where everything was already available before startup, which missed the awkward bit entirely.

Who decides the bracket's disposition once that existing result is recovered?

Daniel, the programmer can attach it to the original attempt; Emma, quality owns disposition, so recovering the result must not create a second acceptance or bypass a hold.

Include a restart during reconciliation as well. Saving a review decision in one place and forgetting it in another would bring the same bracket back for another round of help.

And a missing-result case. Not every uncertain attempt will conveniently produce the evidence the happy recovery test needs.

Offline cases now pass: late result attaches to its attempt, missing result stays awaiting review, and restarting again retains the reviewed decision; no new request is sent from either uncertain state.

Did quality try the distinction between recovered evidence and permission to release?

Yes, with the operator and programmer; they recognised the held bracket and did not treat the recovered pass as a release decision, then followed the recorded review route.

The corrected startup handler is installed and checked against the retained original attempt; its existing result is reconciled once, and quality has made the disposition decision. The pending-means-resend shortcut is gone.

Keep those deliberately delayed cases in the regression set. Ordinary fast replies will rarely expose this mistake, which is why it can look well tested until the first badly timed restart.