A success message does not prove your form saved anything

A form can show a cheerful confirmation while the server rejects the request. If you're debugging that behaviour, start with a small contract: the interface should show success only after the request returns an accepted result.

Here is an illustrative handler with the state transitions separated from the request. send and setState are injected so the behaviour can be checked without a live server:

async function saveEntry(payload, send, setState) {
  setState({ status: "saving" });
  try {
    const response = await send(payload);
    if (!response.ok) throw new Error("Request was rejected");
    setState({ status: "saved" });
  } catch {
    setState({ status: "error", message: "The save could not be confirmed." });
  }
}

// Example transport, called only when the user submits:
const sendEntry = (payload) => fetch("/api/entries", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(payload)
});

An HTTP error response can still fulfil the fetch promise. Check response.ok before showing success. A network failure can reject the promise, which follows the error path here. MDN documents both behaviours: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch

Three focused checks make the change reviewable:

1. An accepted response ends in saved.
2. A rejected response ends in error and never sets saved.
3. A thrown network error also ends in error.

The handler's saved state only means that the client received an accepted response. Verify that the API's contract actually includes a completed write. If the API returns an asynchronous acknowledgement, use a different state and check the eventual outcome. A timeout may leave the server outcome unknown; do not retry a non-idempotent write blindly. Repeated submissions need their own agreed behaviour and checks.

When explaining this in an interview, name the original failure, the boundary you checked, and why those cases establish the fix. That is more useful than narrating every file you opened.

I created a free ten-question software engineering interview sample for more rehearsal prompts: https://payhip.com/b/Jx0YT. The full paid Software Engineering Interview Playbook is here: https://payhip.com/b/RImif.

Comments

[Elijah Brown]

The line about a timeout leaving the server outcome unknown is the important one. A common way to make the retry safe is to generate a submission ID when the form opens, send it as an idempotency key, and reuse it on every retry of that same submission, so the server can return the stored result instead of writing a second row. If the person edits the form and submits again, that is a new submission and gets a new key.