Microtask Starvation and Queue Priority

A Page That Freezes but Never Errors

Your teammate ships a feature that uses MutationObserver to synchronize two DOM trees. In testing, it works. In production, with a complex DOM, the page freezes indefinitely. No error in the console. No stack overflow. DevTools shows the page is "running" but nothing renders.

The CPU is pegged at 100%. The only fix is to kill the tab.

This is microtask starvation — and unlike stack overflow, the engine won't save you with an error.

The Mental Model

How Starvation Happens

The event loop's microtask checkpoint drains the queue completely. If a microtask schedules another microtask, the checkpoint continues. If this happens indefinitely, the loop never proceeds to rendering or the next task.

// This freezes the page. Forever.
function starve() {
  queueMicrotask(starve);
}
starve();

Compare with the macrotask version:

// This does NOT freeze the page.
function breathe() {
  setTimeout(breathe, 0);
}
breathe();

The setTimeout version schedules a new task for each iteration. Between tasks, the event loop can process microtasks, render, and handle user input. The queueMicrotask version never leaves the microtask checkpoint.

The Difference: Stack Overflow vs. Microtask Starvation

Microtask starvation is more dangerous because there's no safety net. The engine has no concept of "too many microtasks" — the spec says to drain the queue, so it drains the queue.

Real-World Starvation Patterns

Pattern 1: MutationObserver Ping-Pong

const observer1 = new MutationObserver(() => {
  // Reacting to tree2 changes by modifying tree1
  tree1.textContent = tree2.textContent + ' synced';
});

const observer2 = new MutationObserver(() => {
  // Reacting to tree1 changes by modifying tree2
  tree2.textContent = tree1.textContent + ' synced';
});

observer1.observe(tree2, { characterData: true, subtree: true });
observer2.observe(tree1, { characterData: true, subtree: true });

// Any change to either tree triggers an infinite loop:
// tree1 changes → observer2 fires (microtask) → modifies tree2
// → observer1 fires (microtask) → modifies tree1 → ...
tree1.textContent = 'hello';

MutationObserver callbacks are microtasks. Two observers watching each other create an infinite microtask cycle.

Pattern 2: Promise-based Polling

// Dangerous: microtask-based polling starves the event loop
async function pollForResult() {
  const result = checkResult();
  if (!result) {
    // This schedules a microtask, not a task!
    return Promise.resolve().then(pollForResult);
  }
  return result;
}

If checkResult() never returns a truthy value, this polls forever via microtasks. The page freezes because each .then() schedules another microtask.

The fix is trivial — use a macrotask:

// Safe: macrotask-based polling yields to the event loop
function pollForResult() {
  return new Promise((resolve) => {
    function check() {
      const result = checkResult();
      if (result) {
        resolve(result);
      } else {
        setTimeout(check, 100); // macrotask — yields to rendering
      }
    }
    check();
  });
}

Pattern 3: Recursive Async Processing

// Dangerous: processes entire array as microtasks
async function processAll(items) {
  if (items.length === 0) return;
  await processItem(items[0]); // each await creates a microtask
  return processAll(items.slice(1));
}

If processItem resolves synchronously (e.g., it's a cache hit), the await just queues a microtask. For a large array, this can starve the event loop because the async recursion keeps adding microtasks faster than they drain.

Production Scenario: The State Sync Library

A state management library syncs state between tabs using BroadcastChannel. Each state change triggers a broadcast, and receiving a broadcast triggers a state update:

const channel = new BroadcastChannel('state-sync');

// Tab A
store.subscribe((state) => {
  channel.postMessage(state); // broadcast changes
});

// Tab B
channel.onmessage = (event) => {
  store.setState(event.data); // update local state
  // This triggers store.subscribe → which broadcasts → which Tab A receives → ...
};

This doesn't cause microtask starvation directly (BroadcastChannel messages are macrotasks), but with a reactive store that uses microtasks internally (like a Proxy-based store that notifies via queueMicrotask), the chain can become: state change -> microtask notification -> subscriber fires -> broadcasts -> received -> state change -> microtask notification ...

The fix: debounce broadcasts with a macrotask, and add cycle detection:

let pendingBroadcast = false;
let receivingBroadcast = false;

store.subscribe((state) => {
  if (receivingBroadcast) return; // break the cycle
  if (pendingBroadcast) return;   // debounce
  pendingBroadcast = true;
  setTimeout(() => {
    pendingBroadcast = false;
    channel.postMessage(store.getState());
  }, 0);
});

channel.onmessage = (event) => {
  receivingBroadcast = true;
  store.setState(event.data);
  receivingBroadcast = false;
};

Defensive Patterns

Microtask Budget

If you must use microtasks for performance but risk unbounded growth, implement a budget:

function processBatch(items, batchSize = 100) {
  let processed = 0;

  function processNext() {
    while (processed < items.length && processed % batchSize !== 0) {
      processItem(items[processed]);
      processed++;
    }

    if (processed < items.length) {
      // Yield to the event loop with a macrotask after each batch
      setTimeout(processNext, 0);
    }
  }

  processNext();
}

Cycle Detection for Observers

let mutationDepth = 0;
const MAX_MUTATION_DEPTH = 10;

const observer = new MutationObserver((mutations) => {
  if (mutationDepth >= MAX_MUTATION_DEPTH) {
    console.error('Mutation cycle detected — breaking loop');
    return;
  }
  mutationDepth++;
  try {
    handleMutations(mutations);
  } finally {
    // Reset after the microtask completes via a macrotask
    setTimeout(() => { mutationDepth = 0; }, 0);
  }
});

Common Mistakes

Challenge: Will It Freeze?

Challenge: Starvation Detection

let count = 0;

function schedule() {
  count++;
  if (count < 1000000) {
    queueMicrotask(schedule);
  }
}

schedule();
console.log('Done scheduling');

setTimeout(() => {
  console.log('Timeout fired, count:', count);
}, 0);

Key Rules