The request
"If it fails, just retry automatically." Ask what "it" does. Loading a catalogue and confirming an order have different consequences.
A read can usually be repeated under the same contract. A write may already have succeeded before the response was lost. A timeout proves that the client stopped waiting; it does not prove the operation failed on the server.
Choose policies explicitly
For catalogue reads, our baseline offers a manual Retry. It avoids hidden loops, works with the loader's latest-intention rule and gives the person control. An optional automatic policy should bound attempts, delay retries, stop on navigation and distinguish temporary failures from invalid requests.
For confirmation, introduce an unknown outcome alongside pending, success and definite rejection. Display "We could not verify the result" when the response is lost. Preserve the same request identity for any retry of that exact intention. Do not generate a new confirmation identity inside every fetch attempt.
Walk through the timeline
| Moment | Browser | Service |
|---|---|---|
| 1 | Sends confirmation K | Receives K |
| 2 | Waits | Commits order for K |
| 3 | Connection drops | Cannot deliver response |
| 4 | Sees network error | Order still exists |
Changing the button label to Failed at moment 4 makes an unsupported claim. Sending a new identity K2 might create a second order. A server-side deduplication contract is needed; a disabled button alone cannot provide it.
Implement the interface decision
Create a remote-submission state independent of the local draft status: idle, pending, accepted, rejected, unknown. Freeze the submitted snapshot while pending. If the result is unknown, offer "Check or retry this submission" using the same snapshot and key, and keep unrelated draft editing separate.
Until your lab service implements the write contract, this is a paper simulation. Do not add an active Confirm button that suggests a real commitment. In the authority module you will implement a limited in-memory service and label its guarantees.
Review exercise
A generated helper retries every exception three times with a fresh random key. Identify two counterexamples: a successful write whose response was lost, and a malformed request that will never become valid through repetition.
Your deliverable is a decision table for success, validation rejection, revision conflict and network uncertainty. Describe the next action for each. The interesting engineering work is deciding what can safely happen again.