A migration script runs `ids.forEach(async (id) => { await save(id); });` and then logs "done", but "done" appears before any save finishes and failures never reach the surrounding try/catch. Why does that happen, and how do you fix it?

## The mechanism, in one line `forEach` discards whatever its callback returns. An `async` function returns a promise. Those two facts together mean `forEach` starts asynchronous work and then immediately forgets about it. ## Walking the execution ```js async function migrate(ids) { try { ids.forEach(async (id) => { await save(id); }); console.log('done'); } catch (err) { console.error('failed', err); // never reached } } ``` Step by step: 1. `forEach` calls the callback with `ids[0]`. The callback body runs synchronously until the first `await`, which suspends it and **returns a pending promise** to `forEach`. 2. `forEach` ignores that promise and immediately calls the callback with `ids[1]`, then `ids[2]`. Now three suspended callbacks and three orphaned promises exist. 3. `forEach` returns `undefined`. 4. `console.log('done')` runs. Nothing has finished. 5. Later, each `save` settles. If one rejects, its promise has no handler and no awaiting parent, so the runtime reports an unhandled rejection — in Node that terminates the process by default on modern versions; in a browser it fires `unhandledrejection`. Either way your `catch` block never sees it. The damage in a migration script is real: you report success before the work is done, you have no idea which records actually landed, and you fire every request at the database at once instead of at a controlled rate. ## Why `await ids.forEach(...)` does not save you ```js await ids.forEach(async (id) => { await save(id); }); // still broken ``` `forEach` returns `undefined`. Awaiting a non-promise resolves on the next microtask tick, so this adds a negligible delay and nothing else. The presence of `await` is what makes this version so dangerous in review: it *looks* correct. ## Fix one: sequential with for...of ```js for (const id of ids) { await save(id); } console.log('done'); // now truly done ``` `for...of` has no callback boundary — the `await` belongs to the enclosing async function, so the function itself suspends at each step. `try/catch` around this behaves exactly as you would expect, and a rejection stops the loop at the failing element. This is the right shape when order matters, when each step depends on the previous one, or when you deliberately do not want to hammer a downstream system. ## Fix two: concurrent with mapped promises ```js await Promise.all(ids.map((id) => save(id))); console.log('done'); ``` Here `map` **does** keep the callback's return value, so you get an array of promises, and awaiting them together makes the function wait for all of them. Note the explicit arrow: writing `ids.map(save)` passes the index and the array as second and third arguments to `save`, which is its own classic bug if `save` accepts more than one parameter. ## Diagnosing it in the wild Symptoms that point straight at this pattern: - A completion log or a resolved response arrives before the work it claims to have completed. - `UnhandledPromiseRejection` in logs with a stack that starts inside a callback, not inside your `try`. - Downstream code reading data that "should" exist and finding it missing on the first run and present on a retry. - A burst of simultaneous outbound requests where the code reads as if it were serial. When you see `forEach(async` in a diff, treat it as a defect on sight. The same reasoning applies to any method that ignores callback return values — `map` is safe because it collects them, `forEach` is not. ## The judgment part Once you have fixed the correctness bug, the remaining question is which fix. Sequential `for...of` is predictable, easy to reason about under failure, and gentle on the downstream system, but slow for large inputs. `Promise.all` over a mapped array is fast but starts everything at once, which for a few thousand ids is a good way to exhaust a connection pool or trip a rate limit. The honest answer in an interview is that you pick based on whether the operations are independent and whether the downstream system can absorb the concurrency — and that for large inputs you want a bounded degree of concurrency rather than either extreme.