The Microtask Checkpoint

• A microtask checkpoint runs whenever the JavaScript execution context stack becomes empty, not only at the end of a big task. Every callback the browser invokes gets one on the way out.
• The checkpoint drains the queue to empty. It does not take a snapshot and process it; it keeps taking the next microtask until there is nothing left, so microtasks queued during the drain are handled in the same checkpoint.
• Promise reactions (then, catch, finally, and the resumption of an await) are microtasks. So are queueMicrotask callbacks and MutationObserver deliveries.
• The checkpoint is re-entrancy-protected: a checkpoint already in progress is not started again from a nested callback, which is what keeps the drain a single flat loop rather than a stack of partial drains.
• Because the checkpoint sits between the task and any rendering, "microtask" is precisely the phase that means before the browser can paint. That is a useful guarantee, not merely a scheduling detail: it is how a framework can batch several state updates and still be certain the user never sees an intermediate state (Reconciliation and Keys).
• When a task is a real user-triggered event dispatch, each listener invocation returns to an empty stack, so a checkpoint runs between listeners. When the same event is dispatched from script — el.click() inside a handler — the stack is not empty, and the checkpoint is deferred until the outer code returns.

1// Freezes the page. The checkpoint never drains.
2function starve() {
3  Promise.resolve().then(starve);
4}
5 
6// Yields. Each iteration ends the task, so the browser
7// gets a rendering opportunity between iterations.
8function breathe() {
9  setTimeout(breathe);
10}
11 
12// The one people write by accident: a "queue drain" whose
13// recursion is bounded only by how much data arrived.
14async function drain(queue) {
15  while (queue.length) {
16    await handle(queue.pop());   // resolves immediately -> microtask
17  }                              // -> no frame until the queue is empty
18}

TASK: a click handler that starts a self-feeding chain

  step  running                    microtask queue          can browser render?
  ----  -------------------------  -----------------------  -------------------
   1    handler()                  -                        no (task running)
   2    queues cb1                 [cb1]                    no
   3    handler returns            [cb1]                    no - checkpoint next

  ==== MICROTASK CHECKPOINT (drain to EMPTY) ====
   4    cb1                        -                        no
   5    cb1 queues cb2             [cb2]                    no
   6    cb2                        -                        no
   7    cb2 queues cb3             [cb3]                    no
   8    ... unbounded ...          [cbN]                    no
  ==== checkpoint never ends ====

  Never reached: rendering opportunity, next task, input dispatch,
  accessibility-tree update. The tab is pinned with the CPU fully busy and the
  profile shows thousands of fast callbacks, not one slow one.

• Use a microtask when you want work done before anything is painted: settling derived state, flushing a batch, normalising a store, resolving a value that the frame about to be produced depends on.
• Use a task when you want the browser to have a chance to paint first. The rule is short enough to remember: microtask for consistency, task for responsiveness (Yielding and Scheduling).
• Bound every recursive promise chain. If a .then can queue another .then based on data — pagination, retry, a queue drain — put a task boundary in the loop so the checkpoint can end (Retries, and the Duplicate Order).
• Do not use await as a yield. If the intent is "let the browser breathe", await something that resolves from a *task* — a timer, a message — not an already-settled value.
• Keep MutationObserver callbacks small. They run in the checkpoint, so a heavy one delays the frame that the mutation was supposed to produce.