In a browser, a callback scheduled with queueMicrotask() calls queueMicrotask() on itself every time it runs. What happens to the page, and will a setTimeout callback that was already pending ever fire?

## The rule that makes starvation possible JavaScript runs one job at a time to completion. Between jobs the runtime performs a *microtask checkpoint*: it takes microtasks — promise reaction jobs, `queueMicrotask()` callbacks — and runs them one after another. The defining detail is that the checkpoint drains the queue **to empty**, and anything enqueued during the drain joins the same pass rather than waiting for the next one. That is deliberate: it guarantees a promise chain settles fully before any timer, event, or rendering step can observe a half-finished state. The same guarantee is the trap. "Drain to empty" has no upper bound and no fairness escape hatch. If every microtask adds one more, the queue is never empty, so the drain never finishes. ## What the code looks like ```js function loop() { queueMicrotask(loop); // schedules the next one before returning } queueMicrotask(loop); setTimeout(() => console.log('never printed'), 0); ``` The timer callback is a task. Tasks only run after the checkpoint completes, and it never completes. The message is never printed, no matter how long you wait. The promise spelling of the same bug is more common in real code, because it does not look like recursion at all: ```js function poll() { Promise.resolve().then(poll); } poll(); ``` ## Why it does not overflow the stack A reasonable guess is that infinite recursion will die with `RangeError: Maximum call stack size exceeded`. It does not. `queueMicrotask(loop)` does not call `loop`; it *enqueues* it. The current invocation returns, the stack unwinds to nothing, and only then does the runtime pull the next microtask. The stack stays one frame deep forever. That is precisely why the failure has no useful stack trace to hand you — it is a scheduling failure, not a depth failure. ## What the user experiences One core is pinned at 100% while the tab does nothing observable. Scrolling, clicking and typing stop responding, because input handlers are dispatched as tasks. Animations and any pending DOM update never appear on screen, because painting happens between tasks, not between microtasks — the DOM may well have been mutated, but the user never sees it. After a while the browser offers to kill the unresponsive page. Nothing is logged, nothing throws, and the console itself becomes unusable because it needs the same thread. ## The same failure in other hosts This is not a browser quirk. Any host that implements the microtask checkpoint drains to empty, so a self-requeuing microtask starves timers and I/O callbacks in a server runtime too — the process burns a core and stops making progress. The mechanism belongs to the language; only the list of starved consumers differs by host. ## Where it comes from in practice Almost nobody writes the loop above deliberately. It appears as: - a "wait until ready" poll implemented with `Promise.resolve().then(check)` instead of a timer, where the condition is set by a task that can now never run — so the poll is unsatisfiable by construction; - a recursive retry whose failure path resolves synchronously, so every attempt costs one microtask and no elapsed time; - a work-queue drainer that pulls the next item with `await` on an already-settled promise, believing that `await` yields to the event loop. ## Handing the loop back The cure is to move the recursion onto the **task** queue so the checkpoint can finish. `setTimeout(loop, 0)` is the portable choice; a `MessageChannel` message is the classic low-latency alternative; `scheduler.yield()` exists in some Chromium browsers as a host-provided way to yield and resume. All three end the current job, letting the runtime run timers, dispatch input, and paint before your next step. Combine that with batching — do a few milliseconds' worth of work per turn rather than one item — so you pay one round trip through the loop per batch instead of per item. ```js function loop() { setTimeout(loop, 0); // now the tab stays responsive } loop(); ``` The distinction worth carrying away: microtasks are for finishing what you started, tasks are for starting again later. Anything that must repeat indefinitely belongs on a task.