Microtask Queue

## The rule in one line A promise callback is **always** delivered asynchronously, on the microtask queue, even when the promise is already settled. There is no fast path that calls it inline. ## What .then actually does `p.then(onFulfilled, onRejected)` does two things. First, it creates and returns a brand-new promise — the *derived* promise — whose fate depends on what your handler returns or throws. Second, it registers your handlers with `p`, and what happens next depends on `p`'s state: - **`p` is pending** — the handlers are stored on `p` as reaction records. Nothing is queued yet. When `p` later settles, the matching reaction is enqueued as a job. - **`p` is already fulfilled or rejected** — there is nothing to wait for, so the engine immediately *enqueues* a promise reaction job. Immediately enqueues; it does not immediately call. That job is a small unit of work: "call this handler with this value, then resolve or reject the derived promise with the result". It sits in the microtask queue with every other pending job. ## Where the job runs JavaScript code runs to completion: once a function starts, the engine finishes it and everything it calls synchronously before doing anything else. Only when the call stack has fully unwound does the runtime reach the point where queued jobs may run — the **microtask checkpoint**. At that checkpoint the queue is drained and your handler is finally invoked. The practical consequence is a strict ordering with three tiers in one turn: all synchronous code first, then all microtasks (promise reactions, `queueMicrotask` callbacks), then whatever the host schedules as a separate task. ``` const p = Promise.resolve('value'); // already fulfilled p.then(v => console.log('A', v)); // job enqueued now, not run now console.log('B'); // runs first // B, then A value ``` ## Attaching handlers late still works Because a settled promise keeps its state and value forever, attaching `.then` seconds or minutes after settlement is perfectly valid — you get a fresh reaction job on the spot. This is what makes it safe to hand a promise around and let several unrelated pieces of code subscribe whenever they are ready. It also means there is no such thing as "missing" a promise result the way you can miss an event that fired before you subscribed. ## Ordering when several handlers are attached Each `.then` call on the same promise registers its own reaction. When the promise settles (or, if already settled, at each call), the jobs are enqueued in registration order and therefore run in registration order at the checkpoint. Two independent subscribers cannot interleave inside one another because each handler itself runs to completion. ## Why the specification forbids a synchronous call If a library sometimes called back inline (value cached) and sometimes asynchronously (value not yet fetched), every consumer would have to defend against both. Code after the `.then` call might or might not have run yet; state might be half-initialised when the handler fires; recursion and re-entrancy bugs appear only under the cached path, which is exactly the path that does not show up in slow-network testing. Forcing one behaviour removes an entire class of Heisenbugs, and it is why other asynchronous APIs increasingly adopt the same discipline: *never* mix synchronous and asynchronous delivery in one function. ## What this is not The microtask queue is not the queue used by `setTimeout`. Timer callbacks are tasks, and the runtime processes at most one task per turn, running the entire microtask queue in between. So a promise reaction registered on an already-settled promise runs *before* a `setTimeout(..., 0)` scheduled earlier in the same synchronous run, even though the timer was requested first. Answering "they both go in the callback queue" collapses the distinction that the question is really testing. ## Diagnosing the mistake in real code The symptom of misunderstanding this is code that reads a variable the handler is supposed to set, immediately after the `.then` call, and finds it undefined: ``` let user; getCachedUser().then(u => { user = u; }); render(user); // always undefined — render runs before the job ``` The fix is not to check whether the promise was cached; it is to move the dependent work inside the handler or `await` it, because the deferral is unconditional. Recognising that unconditional deferral — and naming the microtask queue as where the job waits — is the whole answer an interviewer is listening for.