In TypeScript, `items.forEach(async item => { await save(item); })` compiles without complaint even though the callback is asynchronous. Why does the type checker accept it, and what goes wrong when it runs?

## Why the compiler is silent Two separate facts combine here, and both are working as designed. First, an `async` function always returns a promise. `async item => { await save(item); }` has type `(item: Item) => Promise<void>`, not `(item: Item) => void`. Second, TypeScript has a deliberate assignability rule: a function type whose return type is `void` accepts a function returning *any* type. `Array.prototype.forEach` declares its callback as `(value: T, index: number, array: T[]) => void`, so `Promise<void>` slots in without comment. The rule exists so that ordinary callbacks with concise bodies do not need braces added just to swallow a return value. The rule's premise is "the caller ignores the result, and ignoring a result is safe". That premise holds for a number. It does not hold for a promise, because a promise is not a result — it is a *handle to work still in progress*, and to a rejection that needs somewhere to go. ```ts declare function save(item: Item): Promise<void>; items.forEach(async item => { await save(item); }); console.log('done'); // prints before a single save has finished ``` ## What actually happens at runtime The emitted JavaScript is unchanged by types, so `forEach` does what it always does: it calls the callback once per element and throws the return value away. - **Ordering and completion.** Every call starts, none is waited on. `forEach` returns as soon as the last callback has been *invoked*, not completed. Any code after the loop — a commit, a response, a log line saying "done" — runs against a half-finished state. - **Concurrency.** All the saves are launched at once. With ten items that is fine; with ten thousand you have just opened ten thousand concurrent operations against a database or an API with no limit. - **Errors.** This is the sharp edge. A `throw` inside an async function rejects its promise instead of propagating to the caller, so a surrounding `try/catch` around the `forEach` catches nothing. Nobody attached a handler to the discarded promise, so the rejection is unhandled: in Node it triggers the process-level unhandled-rejection behaviour, and in a browser it fires an `unhandledrejection` event and is usually only visible in the console. ```ts try { items.forEach(async item => { await save(item); }); // throws inside → rejection } catch (e) { // never reached } ``` So the failure mode is the worst kind: silent partial success, with the error visible only in a place nobody is watching. ## Fixing it Decide first whether the work should be sequential or concurrent — the two fixes are not interchangeable. **Sequential**, when order matters or you must not overwhelm the downstream service: ```ts for (const item of items) { await save(item); } ``` A `for...of` loop inside an async function awaits each iteration, errors propagate normally to an enclosing `try/catch`, and the loop stops at the first failure. **Concurrent**, when the calls are independent: ```ts await Promise.all(items.map(item => save(item))); ``` `map` returns the array of promises rather than discarding it — that is the whole difference — and `Promise.all` gives you one awaited result that rejects on the first failure. Use `Promise.allSettled` when you want every item attempted and a report of which failed, and add a concurrency limit when the fan-out is large. Note that `map(item => save(item))` needs no `async` at all: returning the promise is exactly what is wanted. Writing `async item => await save(item)` there is harmless but adds a wrapper for nothing. ## Preventing the class of bug **Type the callback honestly.** If you are designing an API whose callback will be awaited, do not declare it `() => void` — say `() => void | Promise<void>` if both are acceptable, or `() => Promise<void>` if you require one. The `void` declaration is a statement that the result is meaningless, and for an awaited callback that statement is false. **Let a linter carry the rule.** The type checker cannot flag this without breaking the void-return rule that legitimate code depends on, so the check lives in typescript-eslint: `no-misused-promises` reports a promise-returning function passed where a void-returning one is expected, and `no-floating-promises` reports a promise-valued expression whose result is never consumed. These are type-aware rules and catch the same shape in event handlers, `setTimeout` callbacks and array methods alike. **Watch the same shape elsewhere.** Anything typed to take a `() => void` callback has this hole: DOM event handlers, `setInterval`, middleware hooks, and framework lifecycle callbacks. The compiler will accept an async function in every one of them.