A MutationObserver watching a container with { childList: true, subtree: true } appends a wrapper element inside that same container from its own callback, and the callback then runs over and over. Why, and how do you break the cycle?

## Why the loop exists at all `MutationObserver` reports mutations by *category and location*, not by author. There is no "ignore changes I made myself" flag in `MutationObserverInit`. So when a callback registered with `{ childList: true, subtree: true }` on `container` runs `container.append(wrapper)`, that append is an observed child-list mutation exactly like any other. A record is queued, the callback is invoked again, it appends again, and each turn produces the next turn's work. The page stays technically responsive between turns but the DOM grows without bound and the main thread never gets a quiet moment. The same shape appears with attributes, and there it is even easier to write by accident: an observer with `{ attributes: true }` that normalises a value by calling `el.setAttribute('data-state', normalise(el.dataset.state))` re-triggers itself on every pass, and only stops if `normalise` happens to be a fixed point. ## Fix 1 — disconnect, write, re-observe This is the pattern to reach for first because it is explicit and does not depend on the shape of the write: ```js const mo = new MutationObserver(() => { mo.disconnect(); container.append(document.createElement('span')); mo.observe(container, { childList: true, subtree: true }); }); mo.observe(container, { childList: true, subtree: true }); ``` It works because `disconnect()` both unregisters and **empties the record queue**, so the mutations you make while disconnected leave nothing pending. The cost is a real blind spot: any change another script makes to the subtree during your write is not just undelivered, it is unrecorded. In a page where a framework may be mutating the same container, that gap is a correctness risk, not just a theoretical one. If you want to stay registered instead, the equivalent is to write and then drop what you caused with `mo.takeRecords()` before returning. It has the same blind-spot problem in reverse: `takeRecords()` discards *everything* queued, including other scripts' mutations, not only yours. ## Fix 2 — make the reaction idempotent Often the better answer. Instead of "a mutation happened, so do the work", write "a mutation happened, so bring the DOM to the desired state if it is not already there": ```js const mo = new MutationObserver(() => { if (container.querySelector(':scope > .wrapper')) return; // already correct container.append(makeWrapper()); }); ``` Now the loop is self-limiting: the write queues one more callback, that pass finds nothing to do, and the cycle stops. Idempotence is also what makes the observer robust when *other* code makes the same change — it does not double-apply. The price is one extra callback turn and a DOM read per turn, which is usually irrelevant next to the correctness win. ## Fix 3 — narrow the registration Sometimes the loop is a symptom of an over-broad registration. If your reaction writes attributes, and you only care about child insertions, do not enable `attributes` at all. If you must observe attributes, use `attributeFilter: ['data-src']` so the `data-loaded` flag you set yourself is invisible to the observer. If your reaction can write into a sibling or a detached node instead of the observed subtree, the loop disappears by construction. ## The guard-flag variant, and its limits ```js let writing = false; const mo = new MutationObserver(() => { if (writing) return; writing = true; container.append(makeWrapper()); writing = false; // ← does not help }); ``` This one is a trap. The flag is reset before the callback returns, but the record your write queued is delivered *later*, when `writing` is already `false`. A guard only works if it is cleared after delivery of the records you caused — which in practice means clearing it from a queued task or, more simply, using `takeRecords()`/`disconnect()` instead. Interviewers like this detail because it separates people who have debugged the loop from people who have read about it. ## Diagnosing it in the wild Symptoms are a growing DOM, a callback whose record arrays are small but endless, and CPU that never drops to idle. In the debugger, log `records.length` and `records[0].type` on every invocation: a self-triggering loop shows a steady trickle of one or two records of the same type with the same `target`, unlike genuine app churn which is bursty and varied. Then ask the decisive question — does this callback write into the subtree it observes? If yes, apply one of the fixes above; if you cannot avoid writing there, idempotence is the fix that keeps working when a third script starts mutating the same container.