Those questions reveal a gap that a normal successful test can miss. An application needs to handle not only the completion of a task, but uncertainty about its outcome. Testing that uncertainty helps teams design recovery that preserves work and gives users a sensible next step.
A click, a completed action and a confirmation are separate events
The interface can register a click before the request reaches the server. The server can perform an action before its confirmation reaches the browser. A broken connection at different moments therefore creates different states.
Consider a hypothetical application that submits a support request. If the connection drops before submission, the user may need to send it later. If the server creates the request but the confirmation is lost, sending it again could create a duplicate unless the application handles repetition appropriately.
The page may remain visible throughout. That does not establish whether the action succeeded. A cached screen, a draft in memory and a confirmed server record describe different things.
Define the expected result before testing. What should the user see if the outcome is unknown? How can the application establish what happened? Which data should remain available during recovery? These are product and implementation decisions, not merely a choice of error wording.
Retrying is not always harmless
An operation is idempotent when repeating the same request has the same intended server effect as performing it once. The term matters because connection failures often leave a client unsure whether its first attempt arrived.
MDN explains that methods such as POST and PATCH are not guaranteed to be idempotent. An application using them needs to consider its own operation and server-side design rather than assuming a retry cannot change the result again.
Disabling a button after a click may reduce accidental repeated clicks. It does not, by itself, establish what happens when a request is retried by another part of the system or after the page is reopened.
For the hypothetical support request, the team should define how a repeated submission is recognised and what confirmation the user receives. Then test that behaviour with approved test data. The useful evidence is the resulting server record and its relationship to the attempt, not only the message on the screen.
Keep this proportionate to the action. Reading a page and creating an order have different consequences. A recovery design should reflect what a repeated or lost operation would actually do.
Test different failures as different cases
Use a staging environment or another authorised test arrangement. Prepare a small representative task and the observations needed to judge it. Avoid creating real purchases or changing customer records merely to produce a connection failure.
Browser network tools can help examine selected conditions. A deliberate disconnection examines another case. Neither should be assumed to reproduce every failure in the full application infrastructure.
For an authorised comparison of network routes, obtain the VPN download from the official source and record the supported client settings. A changed route can be useful test context, but a VPN is not a complete fault-testing system and does not replace controlled failure cases.
Record when the change occurs: before submission, while waiting for a response or after confirmation. Also note the client state and the relevant server evidence. If those observations are missing, two tests labelled “connection lost” may be exercising different problems.
Keep other inputs stable. Changing the account, browser session and network arrangement together makes it harder to identify which condition explains the result.
Recovery should explain what the user can do
A useful recovery state distinguishes a known failure from an uncertain outcome. If the application has confirmation that the action completed, show it. If it does not yet know, avoid presenting uncertainty as either a definite success or a definite rejection.
Understanding how a VPN works helps keep network-path changes separate from the application's own save and retry behaviour. Restoring a connection does not determine whether the previous action was performed, nor does it fix a missing server-side recovery mechanism.
Preserve appropriate draft material where the design allows it, and explain what can be retried safely. Consider what happens after a refresh or sign-in as well as during the original session. Work that survives a short interruption may still disappear when the user follows an unclear recovery instruction.
After a repair, repeat the interrupted case and a normal successful task. Check both the visible result and the stored outcome. The goal is an application that helps the user finish the job without losing work, creating duplicates or forcing them to guess what the system has already done.
