Skip to content
tezvyn:

Promise.allSettled(): Never Fail a Batch of Promises

Source: developer.mozilla.orgHardHow cards are made

Promise.allSettled(): Never Fail a Batch of Promises

Promise.allSettled() waits for every promise in a set to finish, success or fail, without short-circuiting. Use it for independent tasks, like multiple API calls, where you need the outcome of each.

Why it exists

Before Promise.allSettled(), if you had ten independent API calls and one failed, Promise.all() would reject immediately, discarding the results of the nine successful calls. This all-or-nothing behavior is problematic for non-dependent tasks. Promise.allSettled() was created to solve this by guaranteeing you get a result for every promise.

The mental model

Think of Promise.allSettled() as a survey collector. It sends out multiple questionnaires (promises) and waits for every single one to be returned, whether it's filled out completely (fulfilled) or returned with a note explaining why (rejected). It then gives you the entire stack of responses to sift through, rather than throwing away the whole batch if one comes back incomplete.

How it works

You pass an iterable, like an array of promises, to Promise.allSettled(). It returns a single new promise that always fulfills once every input promise has settled. Its fulfillment value is an array of objects, where each object describes an outcome. Each outcome object has a 'status' property ('fulfilled' or 'rejected'). If fulfilled, it also has a 'value' property. If rejected, it has a 'reason' property. The order of the results array always matches the order of the input promises.

When to use it

Use this when you have multiple asynchronous tasks that are not dependent on one another. For example, fetching data for several unrelated widgets on a dashboard. You want to show the data for widgets that loaded successfully and an error state for those that failed, without the entire page breaking because one API call failed.

When not to use it

Do not use it when subsequent operations depend on all promises succeeding. If you need to fail an entire transaction if any single part fails, use Promise.all(). Using allSettled() in that scenario forces you to manually check for any rejections before proceeding, which is exactly the behavior Promise.all() provides automatically.

One canonical example

Imagine fetching a user's details and their list of friends from two different endpoints. One might fail, but you still want to display the other.

const p1 = api.fetchUserDetails(userId);
const p2 = api.fetchUserFriends(userId);
Promise.allSettled([p1, p2]).then(results => {
const userDetailsResult = results[0];
if (userDetailsResult.status === 'fulfilled') {

// render user details with userDetailsResult.value } else { // show an error for the user details section }

const friendsResult = results[1];
if (friendsResult.status === 'fulfilled') {

// render friends list with friendsResult.value } }); This ensures a partial failure doesn't result in a total UI failure.

Interview question

What is the primary reason to use Promise.allSettled() over Promise.all() for multiple asynchronous tasks?

  • a.To obtain a status report for every task, allowing individual handling of successes and failures.Correct
  • b.To optimize performance by running all promises concurrently and discarding failed ones.
  • c.To ensure the entire operation fails immediately if any single task encounters an error.
  • d.To retrieve the result of the first promise that completes, whether it succeeds or fails.
Why?

Promise.allSettled() is designed to provide an outcome for every promise in the batch, whether it fulfilled or rejected, allowing for graceful handling of partial failures. Option C describes Promise.all(), which short-circuits and rejects the entire batch if any promise fails.

Just read this? Test yourself on what you have been reading.

Read the original → developer.mozilla.org

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on javascript — each one lists the topics its interview covers.

See open roles