How does Promise.any decide what to settle with, and what exactly is the rejection value when every promise you passed it fails?

## What the combinator promises `Promise.any(iterable)` — standardised in ES2021 — returns a promise that **fulfils with the first fulfilment** among the inputs. Rejections that land before that first fulfilment are not fatal; they are recorded and the combinator keeps waiting. Only when every input has rejected does it give up. This is the piece that distinguishes it from the first-past-the-post behaviour of `Promise.race`, which adopts whichever outcome arrives first, success or failure. `any` is what you want for redundancy: three mirrors of the same asset, two regional endpoints, a cache lookup alongside an origin fetch. One dead source should not sink the operation. ```javascript const fail = (msg) => Promise.reject(new Error(msg)); Promise.any([fail('mirror-1'), Promise.resolve('payload'), fail('mirror-3')]) .then(console.log); // payload ``` ## The all-failed case: AggregateError When the last input rejects, `any` has N reasons and must reject with exactly one value. Wrapping them in an array would be a poor error — `catch` blocks expect an `Error`. So the language introduced `AggregateError`, an `Error` subclass whose job is to carry several underlying failures: ```javascript Promise.any([fail('a'), fail('b')]).catch((err) => { console.log(err instanceof AggregateError); // true console.log(err instanceof Error); // true console.log(err.errors.map((e) => e.message)); // [ 'a', 'b' ] }); ``` Three properties of that object are worth knowing precisely: - **`errors` is an array of the reasons, in input order.** Index `i` of `errors` corresponds to entry `i` of the iterable, regardless of which failed first in time. That correspondence is what lets you report "mirror-3 returned 503" rather than "something failed". - **`errors` is non-enumerable.** It does not appear in an object spread or in `Object.keys`, so a logger that shallow-copies the error can drop it. Read `err.errors` explicitly when logging. - **`AggregateError` is directly constructible** — `new AggregateError([e1, e2], 'all sources failed')` — which is how you would rethrow the same shape from your own fan-out helper. The message is supplied by the engine (commonly "All promises were rejected"); the part you should rely on and assert against in tests is `errors`, not the wording. ## The empty-iterable asymmetry `Promise.any([])` rejects **immediately** with an `AggregateError` whose `errors` array is empty. That is the opposite of `Promise.race([])`, which stays pending forever. The reasoning is consistent with each combinator's contract: `any` must produce a fulfilment from some input, and with no inputs it can never do so, so the failure is knowable up front; `race` has no outcome to adopt and no failure condition to report, so it simply never settles. Interviewers like this pair because it separates people who memorised the happy path from people who read the semantics. ## What it does not do `any` gives you no cancellation. When the first fulfilment arrives, the still-pending inputs keep running: the other two mirror requests complete, consume bandwidth and quota, and their responses are discarded. If those calls have side effects — writes, charges, rate-limit consumption — fan-out with `any` multiplies them by the number of sources. Nothing in the combinator can stop that; a promise is a handle on a result, not on the work behind it, so stopping requires an abort mechanism on the underlying operation. It also gives you no partial information on the way to a success. If two of three sources fail but the third succeeds, the two failures are silently dropped — they exist only in the `AggregateError` that is never created. If you need to alert on degraded mirrors, attach your own logging to each source before handing it to `any`: ```javascript const watched = sources.map((p, i) => p.catch((e) => { log.warn({ source: i, err: e }); throw e; }), ); const payload = await Promise.any(watched); ``` Rethrowing inside the `catch` is essential — swallow the error and that source now looks like a fulfilment, so `any` would resolve with `undefined` from the first failure. ## Choosing between the two Use `race` when the earliest settlement *is* the answer you want — a deadline, a cutoff, a first-signal-wins gate. Use `any` when you want the earliest **usable** answer and treat individual failures as noise. Reaching for `race` on a redundancy problem is the classic mistake: the fastest source to fail wins, and the whole operation rejects while healthy sources are still in flight.