❯ Async, Promises & the Event Loop

Roughly 20% of a typical loop — and 20% of the mock exam here.

One rule explains most ordering puzzles

The engine runs one task to completion, then drains the entire microtask queue, then renders, then takes the next task. Promise handlers, await continuations and queueMicrotask callbacks are microtasks; timers, I/O callbacks and events are tasks.

setTimeout(() => console.log('a'), 0);
Promise.resolve().then(() => console.log('b'));
console.log('c');
// c, b, a

Two corollaries interviewers probe. First, everything in an async function before its first await runs synchronously, so a validation throw up there still rejects rather than throwing at the call site. Second, await yields to the microtask queue even when its operand is a plain value, so await 42 still defers the rest of the function.

A runaway microtask loop is worse than a slow task: the queue must empty before the next task or paint, so the page hangs with no long frame in the profiler. In Node, process.nextTick has its own queue that drains before promise microtasks once a task callback returns, and recursive nextTick can starve both promises and I/O. The one place that ordering flips is the top level of an ES module, whose evaluation already runs inside a microtask drain — verify with a timer callback, not with a bare script, if you ever have to demonstrate it.

Promises: eager, single-settlement, uncancellable

The executor passed to new Promise runs synchronously — the work starts at construction, not at await. A promise settles once and never changes, which is why promises cannot be cancelled; you cancel the underlying work instead.

then returns a new promise that settles with whatever the handler returns or throws. Returning a promise from inside a handler adopts it, which keeps chains flat — and forgetting to return it is the classic bug where the chain continues before the work finishes.

p.then(onOk, onErr) does not catch errors thrown inside onOk; p.then(onOk).catch(onErr) does. Prefer the trailing .catch. .finally runs either way, receives no argument and passes the outcome through, but a throw inside it replaces that outcome.

Combinators, in the order they come up:

• Promise.all — rejects on the first rejection; the others keep running uncancelled.
• Promise.allSettled — never rejects; one {status, value} or {status, reason} per input. The right tool when you need every result plus a failure report.
• Promise.race — settles with the first settled input, fulfilled or rejected. It does not cancel the loser, so pair a fetch race with an AbortController.
• Promise.any — first fulfillment wins; rejects with an AggregateError only if all inputs reject.

Non-promise entries are passed through Promise.resolve, so plain values and any thenable work.

async/await in practice

Two sequential awaits over independent work cost the sum of both. Start them first, then await together:

const [a, b] = await Promise.all([getA(), getB()]);

forEach ignores the promise its callback returns, so items.forEach(async (i) => await save(i)) never waits. Use for (const i of items) await save(i) for sequential work, or await Promise.all(items.map(save)) for parallel.

Remember that promises are eager: urls.map(u => fetch(u)) starts every request immediately, so awaiting them in a loop does not limit concurrency. To bound it, map to functions and run them through a pool.

return await work() inside try/finally is the one case where the redundant-await lint is wrong — without the await, the function leaves the stack before work settles, so finally and catch never see it.

Failures, timers and cancellation

fetch fulfills on 404 and 500; only a network failure or CORS block rejects. Check response.ok before parsing, or an error page flows into .json() as data.

An unhandled rejection terminates a Node process (15 and later) and fires unhandledrejection in browsers, so attach handlers in the same tick the promise is created. setInterval queues its next run regardless of callback duration and drifts; recursive setTimeout schedules after the previous run finishes. And sleep is just new Promise((r) => setTimeout(r, ms)) — there is no built-in.