Handling Partial Failures in Batch Requests

The plain-language idea

Some UI actions look like one action but are actually many independent requests fired together: bulk-deleting a set of selected items, submitting several related updates at once. A common mistake is writing that as if it were a single atomic operation — one loading state, one "success" or "failure" message at the end. In reality, each request in the batch succeeds or fails on its own. A permission issue might block one specific delete; a transient error might hit a different one; the rest go through fine. Reporting that as one flat outcome is actively misleading either way: "success" hides the items that actually failed and still need attention, and "failure" hides the items that actually went through, which can lead a user to retry an action that already partly happened.

The honest version of this UI has to know, precisely, which items succeeded and which failed, and say so.

See it in a real thing: bulk-deleting selected items

The tool for firing independent requests and getting every individual result, regardless of whether some of them failed, is Promise.allSettled. It's a deliberate contrast with Promise.all, which rejects the moment any single promise in the batch rejects — exactly the wrong behavior here, since one failed delete shouldn't prevent finding out whether the other nine succeeded.

type DeleteResult = { id: string; ok: true } | { id: string; ok: false; reason: string };

async function deleteItem(id: string): Promise<DeleteResult> {
  const res = await fetch(`/api/items/${id}`, { method: "DELETE" });
  if (res.ok) return { id, ok: true };
  const body = await res.json().catch(() => ({}));
  return { id, ok: false, reason: body.message ?? `Request failed (${res.status})` };
}

async function deleteSelected(ids: string[]) {
  const settled = await Promise.allSettled(ids.map(deleteItem));

  // Every entry resolves (deleteItem never throws), so each is a "fulfilled"
  // settlement wrapping either an ok or a failed DeleteResult.
  const results = settled.map((entry) =>
    entry.status === "fulfilled" ? entry.value : { id: "unknown", ok: false as const, reason: "Unexpected error" },
  );

  const succeeded = results.filter((r) => r.ok);
  const failed = results.filter((r) => !r.ok);

  return { succeeded, failed };
}

const { succeeded, failed } = await deleteSelected(selectedIds);

if (failed.length === 0) {
  showToast(`${succeeded.length} deleted.`);
} else if (succeeded.length === 0) {
  showToast(`Delete failed for all ${failed.length} items.`);
} else {
  showToast(
    `${succeeded.length} of ${succeeded.length + failed.length} deleted. ` +
      `${failed.length} failed: ${failed.map((f) => f.reason).join(", ")}`,
  );
}

// Remove only the successfully deleted ids from local UI state — the
// failed ones stay visible and selected, so the user can see exactly
// what still needs attention (and retry just those).
removeFromList(succeeded.map((r) => r.id));

What people usually miss

Watch out

• Promise.all is the wrong tool for an intentionally-independent batch. It rejects as soon as any one promise rejects, discarding the results of everything else that may have already succeeded — exactly backwards for a batch where partial success is a real, expected outcome.
• A batch operation function itself should rarely throw. Individual request failures are data (a result to report), not exceptions to propagate — catching each request's own failure and returning it as a result, as deleteItem does above, is what makes Promise.allSettled actually useful here.
• A flat "success" message after a partial failure is worse than an error message. It tells the user their action fully worked when it didn't, and the items that silently failed can go unnoticed until something else surfaces the inconsistency later.
• A flat "failure" message after a partial success causes duplicate-action bugs. A user who believes nothing happened may retry the whole batch, re-attempting the items that already succeeded the first time.
• The UI needs to reflect per-item state, not just a toast. If nine of ten items disappeared from a list and one didn't, that one item staying visible (ideally with its own error) is what actually communicates what happened — a toast alone is easy to miss or dismiss.

Why this matters in interviews

"What happens if 2 out of 10 items in a bulk action fail?" is a real, specific probe for whether a candidate defaults to atomic all-or-nothing thinking or actually reasons about a batch of independent requests — naming Promise.allSettled and itemized feedback by name is the concrete signal of the latter.