When Promise.all fulfils, in what order do the values appear in the resulting array, and what happens to non-promise entries in the iterable you pass it?

## Input order, not completion order The single most useful property of `Promise.all` is that the output array mirrors the **input iterable positionally**. Internally the combinator walks the iterable, and for entry number *n* it attaches a fulfilment handler that writes the value into slot *n* of a pre-sized result array, decrementing a counter of outstanding entries. When the counter hits zero the aggregate fulfils with that array. Nothing about the order in which the handlers fire influences where a value lands. ```js const slow = new Promise(res => setTimeout(() => res('slow'), 100)); const fast = Promise.resolve('fast'); Promise.all([slow, fast]).then(console.log); // ['slow', 'fast'] ``` `fast` settled first, but it still occupies index 1. This determinism is what makes destructuring idiomatic: ```js const [user, orders, settings] = await Promise.all([ fetchUser(id), fetchOrders(id), fetchSettings(id), ]); ``` If results came back in completion order this pattern would be a race condition, and every call site would need a tag to identify which value was which. ## Non-promise entries pass through `Promise.all` does not require its entries to be promises. Each entry goes through `Promise.resolve`, which has three cases: an actual native promise is returned as-is; a **thenable** (any object with a callable `then` method) is adopted, so its `then` is invoked and its outcome becomes the entry's outcome; anything else is wrapped in an already-fulfilled promise. ```js Promise.all([1, 'two', Promise.resolve(3)]).then(console.log); // [1, 'two', 3] ``` The practical value is that you can mix cached-or-fetched values without special-casing: ```js const rows = ids.map(id => cache.get(id) ?? fetchRow(id)); const all = await Promise.all(rows); // cached entries need no wrapping ``` Note that a wrapped plain value still fulfils asynchronously as far as your `then` callbacks are concerned — the aggregate never settles synchronously, even when every entry is a plain value. ## The empty case `Promise.all([])` fulfils with `[]`, and it does so as soon as it can rather than hanging. The same holds for `Promise.allSettled([])`. This matters whenever the batch is built at runtime: an empty input is a legitimate no-work case, not an error, so guard clauses that treat a zero-length result as a failure will misfire. ## Any iterable, not just arrays The argument is an iterable, so a `Set`, a `Map`'s `values()`, a generator, or the result of `array.map()` all work. Order is the **iteration order** of that iterable, which is stable for arrays and Sets. Passing a non-iterable rejects the returned promise with a `TypeError` rather than throwing synchronously, so a `.catch` still sees it. ## The same mapping in allSettled `Promise.allSettled` preserves the same index correspondence, which is what makes error attribution possible: ```js const results = await Promise.allSettled(ids.map(id => fetchRow(id))); results.forEach((r, i) => { if (r.status === 'rejected') console.error(`row ${ids[i]} failed`, r.reason); }); ``` Without the guarantee that `results[i]` corresponds to `ids[i]`, you would have to bake the identifier into every rejection reason yourself. ## Where the ordering guarantee stops Ordering applies to the *results*, not to the *work*. The promises were created before the combinator ever saw them, so the underlying operations were already started, in whatever order the runtime and the host got to them, and they complete in whatever order they complete. `Promise.all` neither sequences them nor throttles them; it just files the answers into stable slots. Any observable side effects the operations perform — writes, log lines, counters — happen in completion order, and code that depends on those landing in array order will be wrong.