In JavaScript, `const results = items.map(async (item) => save(item));` gives an array of pending promises rather than saved results, and `items.forEach(async (item) => { await save(item); });` returns before anything has been saved. Explain both behaviours and give the correct way to save every item.

## One rule explains both symptoms An `async` function returns a promise no matter what its body does. It cannot return a plain value, because the caller is handed the promise the moment the body reaches its first `await` — long before any result exists. Array methods know nothing about promises; they just call your function and do whatever they normally do with the value it returns. Every surprise in this area follows from combining those two facts. ## `map` collects promises, not results ```js const results = items.map(async (item) => save(item)); console.log(results); // [Promise { <pending> }, Promise { <pending> }, ...] ``` This is not a bug in `map`; it is `map` working exactly as specified. The useful part is that all the callbacks have already been invoked, so every `save` is already in flight — you just need to wait for the collection: ```js const results = await Promise.all(items.map((item) => save(item))); ``` Note the callback here does not need to be `async` at all if it only forwards the promise. Make it `async` when there are several steps per item: ```js const rows = await Promise.all( items.map(async (item) => { const saved = await save(item); return { id: saved.id, ok: true }; }) ); ``` Awaits *inside* one callback sequence only that item's own steps; different callbacks still overlap with each other. ## `forEach` throws the promise away `forEach` is specified to ignore its callback's return value and always evaluate to `undefined`. With an async callback that means: ```js items.forEach(async (item) => { await save(item); }); console.log('done'); // logs immediately — nothing has been saved yet ``` Three things go wrong. First, the enclosing function continues as if the work were complete, so anything downstream — closing a connection, sending a response, ending a test — happens too early. Second, there is no way to know when the saves finish, because the only handles to them were discarded. Third, if one `save` rejects, that rejection has no handler attached and is reported as an unhandled rejection; in Node that terminates the process by default. A `try`/`catch` around the `forEach` call catches none of it, because the callback's failure never travels back through `forEach`. ## The other array methods `filter` is the quietest trap. A predicate that is async returns a promise, and every promise object is truthy, so the filter keeps everything: ```js [1, 2, 3].filter(async (n) => n > 2); // [1, 2, 3] ``` The workaround is to compute the decisions first and then filter synchronously: ```js const keep = await Promise.all(items.map((item) => isValid(item))); const valid = items.filter((_, i) => keep[i]); ``` `sort` has the same problem — an async comparator returns a promise, which coerces to `NaN` when compared numerically, producing an implementation-defined order. Resolve the sort keys first, then sort synchronously. `some` and `every` fail the same way, since a pending promise is always truthy. ## When you actually want sequencing If each item must be processed strictly after the previous one, a plain loop is the clearest tool, because `await` in a loop body does exactly that: ```js for (const item of items) { await save(item); } ``` The `reduce`-based chain achieves the same thing when you prefer an expression, though it is harder to read: ```js await items.reduce((prev, item) => prev.then(() => save(item)), Promise.resolve()); ``` ## The rule of thumb Only `map` combines cleanly with async callbacks, and only because you then hand the resulting array to `Promise.all`. For anything else, either resolve the values first and use the array method synchronously, or write the loop. And treat an `async` callback passed to `forEach` as a defect on sight — a linter rule for it pays for itself.