A connection can fail at the most confusing moment: after someone presses save but before the application receives confirmation. The person may not know whether the server completed the action. A dependable web app acknowledges that uncertainty and provides a safe way to resolve it. Start with the actions where repeating the request could create duplicate work or an unwanted commitment.
Distinguish three different states
Consider an Alice Springs supplier entering a large order. A draft that has not been sent, a submission still waiting for a response and a confirmed saved order are different states. Label them accordingly. Do not show saved simply because the browser accepted a click. If the connection drops, preserve the entered work where appropriate and explain that confirmation is pending. A customer or staff member should not need to infer the outcome from a spinning icon that never changes or a vague message asking them to try again.
Check the server before repeating the action
An interrupted response does not prove the server did nothing. For important submissions, use a request identifier or another appropriate mechanism to determine whether the intended action already completed. The implementation should make repeat attempts safe within the provider and application contracts. MDN's Fetch API guidance describes network failures and response handling, but the business outcome still needs explicit application logic. Ask the developer to demonstrate a connection failure after processing begins, because disconnecting before the first request tests a much easier and less revealing case.
Keep local drafts proportionate
Saving a draft in the browser can protect work, but it also creates questions about shared computers, sensitive content and how long the draft remains. Choose an approach that suits the information involved. Make the draft's location and limitations understandable where they affect the user. If two people edit the same record while disconnected or delayed, do not silently overwrite one person's work when the connection returns. Provide a conflict strategy, such as comparing changes or requiring a refresh before applying an update to a newer record.
Test interruption at several moments
Rehearse a dropped connection before sending, during processing and after the server saves but before confirmation appears. Check both the user interface and the final records. Your recovery requirements should include:
- A visible distinction between unsaved, pending and confirmed work.
- A way to resolve an uncertain outcome without blind duplication.
- A deliberate policy for local drafts and shared computers.
- A clear response when the record changed elsewhere during the interruption.