What is the microtask checkpoint in a JavaScript runtime, and what exactly does the engine do with the microtask queue when it reaches one?

## The two queues A JavaScript runtime keeps work in (at least) two places. **Tasks** are coarse units of work handed to it by the host: a timer callback, an event handler, the initial evaluation of a script. **Microtasks** — the specification calls them *jobs* — are fine-grained continuations of JavaScript that is already in flight: promise reaction jobs and callbacks passed to `queueMicrotask`. The loop that connects them is deliberately asymmetric: 1. Take **one** task and run it to completion. 2. Perform a **microtask checkpoint**: drain the microtask queue to empty. 3. Go back to step 1. Step 2 is where candidates lose the point. Interviewers want to hear "drains to empty", not "runs the next one". ## What draining to empty means At the checkpoint the engine repeatedly removes the front microtask and runs it. If a microtask enqueues another microtask, the new job is appended to the *same* queue and is picked up in the *same* drain — the engine re-checks whether the queue is empty after every job. It leaves the checkpoint only when a check finds nothing left. ``` setTimeout(() => console.log('task'), 0); queueMicrotask(() => { console.log('micro 1'); queueMicrotask(() => console.log('micro 2')); }); console.log('sync'); // sync, micro 1, micro 2, task ``` `micro 2` did not exist when the drain started. It still runs before `task`, because the drain re-examines the queue rather than processing a snapshot of it. This is exactly why a promise chain resolves fully within one checkpoint. Each `.then` hop enqueues a job only when the previous one finishes, so a five-step chain is five jobs enqueued one at a time — and all five complete before the runtime looks at the task queue again. ## Where the checkpoint sits in the specification ECMAScript defines the language-level rule: a job runs only when the execution context stack is empty, so jobs never interrupt running JavaScript. Hosts formalise the surrounding loop — the HTML specification's phrase is literally "perform a microtask checkpoint", and it happens after each task, with the runtime free to take its own steps (input, painting, its own bookkeeping) only afterwards. Server runtimes have the equivalent drain between the callbacks they dispatch. The precise placement of extra checkpoints is a host concern; the invariant every host shares is that microtasks never interleave with a task and always finish before the next one begins. ## Why the design exists Two guarantees fall out of drain-to-empty. **Atomicity of a logical operation.** A promise chain is one conceptual operation split across several callbacks. Draining to empty means nothing external — no timer, no click, no I/O callback — can observe the system halfway through that chain. State assembled across `.then` hops is never seen half-built by unrelated code. **Ordering that does not depend on speed.** Because the drain is exhaustive, the relative order of microtasks depends only on the order they were enqueued, never on how long anything took. That makes promise-based code deterministic in a way callback-plus-timer code never was. ## The cost of the same property The drain has no budget and no fairness mechanism. Everything in the queue runs before the runtime regains control, so a large amount of microtask work extends the current turn: the next task waits, and so does anything the host wanted to do between tasks. A microtask is therefore the right tool for a continuation that must settle before anyone else looks, and the wrong tool for chunking a long computation — for that you need work that is genuinely a *task*, which hands control back. ## The distinctions to keep straight - **One task per turn, all microtasks per turn.** The asymmetry is the whole rule. - **Enqueued-during-drain jobs are not deferred.** They join the current drain; there is no snapshot. - **Order within the queue is FIFO**, and each job runs to completion — jobs never nest or interleave. - **A microtask cannot be pre-empted.** There is no yield point inside one; run-to-completion applies to jobs exactly as it applies to tasks. ## How to answer this out loud State the loop (one task, then drain to empty, then the next task), stress that newly enqueued microtasks join the same drain, give the two-line snippet as evidence, and name the guarantee it buys: no external work observes a promise chain mid-flight. That is a complete answer, and it is the foundation every ordering question in this area rests on.