Promise.all vs Promise.allSettled

WHAT THIS TESTS This checks whether you can pick between fail-fast and collect-all semantics based on whether partial success is acceptable.

A GOOD ANSWER COVERS Promise.all has fail-fast semantics. It fulfills with an ordered array of all results only if every input fulfills, and it rejects immediately with the first rejection reason if any input fails, discarding the other results from your perspective even though those operations continue. Promise.allSettled never rejects because an input rejected; it waits until every input has settled, then fulfills with an array of result descriptor objects. Each descriptor has a status of fulfilled with a value field, or rejected with a reason field. This lets you inspect the outcome of every operation independently. The choice hinges on intent: use all when you genuinely need everything to succeed and want to abort early on any failure, and use allSettled when each operation is independent and you want all of them attempted with per-item outcomes.

COMMON WRONG ANSWERS Thinking allSettled can reject, that it cancels nothing differently, or that all returns partial results on failure. Confusing the descriptor shape, or reaching for all in a batch job where one bad item should not sink the rest.

LIKELY FOLLOW-UPS The exact shape of the settled descriptors, how race and any differ, how to extract just the fulfilled values from allSettled, and how this interacts with bounded concurrency.

ONE CONCRETE EXAMPLE A notification service sends the same message across email, SMS, and push concurrently, and you want to deliver on whatever channels work and log which failed. With Promise.all, a single failing channel would reject the whole operation and hide the successes. With Promise.allSettled, you get a descriptor per channel, mark the fulfilled ones as delivered, collect the rejected ones with their reasons for retry or alerting, and never lose visibility into partial success.