Handle async failures without losing user work

The decision

An asynchronous operation has at least three visible states: pending, completed, and failed. A button that starts a request should explain which state applies. Keep the user’s input until completion is confirmed. A rejected promise should lead to an actionable message, while diagnostic details stay on the server.

A worked example

A draft-writing form sends a note to an API. The API may time out after the model accepted the work. Clearing the note immediately destroys the only copy. Keep the note in local component state, disable duplicate submissions while the request is pending, and show a retry option that preserves the input. If work continues on the server, return a job ID so the browser can ask about the same operation.

How to put it into practice

1. Use try/catch around awaited work and finally for cleanup that must happen in both outcomes.
2. Distinguish network failure from a successful HTTP response that reports an application error.
3. Do not use one global loading flag for unrelated operations. Tie state to the current operation or job.
4. Decide whether retry starts new work or checks existing work. Expensive operations need a stable request identifier.

async function submitDraft(note) {
  const response = await fetch("/api/draft", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ note })
  });
  if (!response.ok) throw new Error("Draft unavailable. Try again.");
  return response.json();
}

A failure to plan for

Try it on your project

Simulate a delayed success, an HTTP 503, and a connection failure. In each case verify that the button becomes usable again, the input remains available, and the displayed message does not expose provider keys or internal exception text.

Primary reference

Read the official documentation →