INTRODUCTION
A retry button promises that another attempt will help the user finish the same action. That promise breaks when the interface treats a missing response as proof that nothing happened.
The useful design question comes before the spinner: if the first attempt succeeded but its reply disappeared, what will the next click do? Product and engineering teams need a shared answer.
Give the action a durable identity
Consider a hypothetical workspace app. A customer clicks Create workspace, the server creates it, and the connection drops before the confirmation arrives. A second click with a fresh request identity could create a second workspace. Disabling the button briefly helps with rapid clicks; it does not resolve a reload, a second tab or a delayed response.
An operation record can carry the user's original intent across those boundaries. The interface resumes that record rather than starting over. Support can look up the same operation instead of asking the customer to reconstruct what happened.
The AWS Builders' Library describes caller-provided request identifiers as a way to distinguish a retry from a genuinely new request. Identical parameters alone cannot express that distinction: someone may intentionally want two identical resources.
Check the contract behind the key
An idempotency key identifies a repeated operation, but its guarantees belong to a particular API. Stripe's reference says repeated requests with the same key return the stored result, including server errors. Keys may be removed after at least 24 hours; reusing a pruned key creates a new request.
That makes retention part of the product design. A support action taken days later cannot assume the provider still remembers the first attempt. Keep the relationship between the local operation and the provider's resource, and reconcile an uncertain outcome before issuing a new command. A changed user intention deserves its own operation, not a quiet mutation of the old one.
A delivered event still needs a completed job
The return journey has its own failure modes. Stripe documents duplicate webhook deliveries and no delivery-order guarantee. A successful manual resend does not automatically cancel its scheduled retries.
For the hypothetical workspace, receipt of a notification and completion of provisioning should therefore be separate states. A durable inbox can record receipt; a worker can track the resulting job. A database constraint or transactional claim prevents two workers from both deciding they are first. If processing fails, the record must remain recoverable rather than permanently marked complete.
External side effects need their own protection. A database transaction cannot atomically include an unrelated email service. Record the pending side effect, use that provider's deduplication contract where available, and expose ambiguous outcomes for reconciliation. A queue alone does not make the entire workflow exactly-once.
Show uncertainty without abandoning the user
Three interface states are more useful than a single generic error:
- Still processing: keep the operation visible and show how its status will update.
- Outcome unconfirmed: check the existing operation; avoid presenting a new submission as harmless.
- Confirmed failure: offer a retry when the system knows it is safe, or explain the next recovery step.
For a low-stakes, reversible action, a lighter implementation may be enough. The counterargument is real: durable orchestration has a maintenance cost. The proportionate choice depends on the damage a duplicate can cause and how reliably it can be undone. Creating a second draft and sending a second invitation do not have the same consequences.
Test the promise before shipping
- Drop the response after the server commits.
- Submit the same operation from two tabs at once.
- Deliver the same event twice and reverse two events.
- Crash the worker between recording receipt and completing work.
- Reopen an old uncertain operation after the provider's retention window.
For each test, check the user-visible result and the recovery trail, not just the HTTP status. The goal is a system that can explain what happened and safely finish what the user meant.
For a broader starting point, see which development workflows to automate first. A product review can start with one costly action and map its uncertain states before adding more automation.
Cover: original AI-generated conceptual illustration with the official Blanche mark composited separately.