Skip to main content

Debugging React Re-renders and Infinite Update Loops with AI Coding Agents

A React component that re-renders too often rarely announces itself. The page works. The tests pass. Then someone notices the fan spinning on a page that displays a list of twelve items, or typing in a search box feels mushy, or the console fills with Maximum update depth exceeded and the tab dies. Between "works" and "dies" sits a long gradient of waste — components re-rendering fifty times per keystroke on a fast dev machine where nobody feels it.

Re-render bugs are the canonical case of what makes front-end debugging hard for an AI coding agent: the decisive evidence lives in runtime state, not in source. An agent reading the component tree sees plausible code. useEffect with a dependency array — looks right. A state update in a callback — looks right. The bug is in what happens when those pieces execute together, and an agent with no runtime instruments falls back to pattern-matching, which for this bug class reliably produces the wrong fix: add the missing variable to the dependency array (now the loop is faster), wrap the update in setTimeout (now the loop is invisible), suppress the warning (now the loop is permanent).

The Traditional Approach​

React DevTools Profiler answers "which components rendered and why" well — if a human is driving it. It records a session, renders flame graphs, and requires someone to recognize which of the highlighted bars matter. None of that output reaches an AI agent as data.

console.log in render is the honest classic. It works, it pollutes the code, and it measures only the component you thought to instrument — re-render storms routinely originate in a parent you didn't suspect.

Reading the code very carefully is what agents do when they have nothing else, and it is exactly the method that produces dependency-array whack-a-mole.

The agnt Approach​

agnt gives the agent two runtime signals that make this bug class tractable, both flowing through the reverse proxy with zero code changes.

Framework diagnostics classify React's own runtime warnings. The proxy captures console output, and when a message carries a known signature — Maximum update depth exceeded, hook-order violations, missing key props, controlled/uncontrolled flips, hydration mismatches — the currentpage tool lifts it out of the raw stream and annotates it with the bug class, the correct remediation direction, and the common wrong fix to steer away from:

currentpage {action: "get", proxy_id: "app"}
{
  "framework_diagnostics": [
    {
      "category": "infinite-render-loop",
      "framework": "react",
      "count": 47,
      "sample": "Maximum update depth exceeded. This can happen when a component calls setState inside useEffect...",
      "fix": "A state update is firing on every render. Find the setState called unconditionally in render or in an effect whose dependencies change each render; stabilize it (useCallback/useMemo for the dep, or guard the update with a condition).",
      "avoid": "Do not silence it by adding the value to the dependency array or wrapping the update in setTimeout/queueMicrotask — that hides the loop, not its cause."
    }
  ],
  "hint": "Recognized framework runtime diagnostics — see framework_diagnostics for the bug class, the correct fix, and the common wrong fix to avoid before editing source."
}

That avoid field exists because of how these bugs actually get "fixed" in the wild. An agent told only "there is an infinite loop" will suppress it; an agent told "the dependency itself is unstable — stabilize it rather than appending it" edits the right line.

Mutation tracking measures the storm directly. A re-render that changes the DOM is visible as mutation churn, and window.__devtool.mutations records it continuously:

proxy {action: "exec", id: "app", code: `
  (function() {
    const before = Date.now();
    return new Promise(r => setTimeout(r, 2000)).then(() => {
      const recent = window.__devtool.mutations.getAdded(before)
        .concat(window.__devtool.mutations.getModified(before));
      const bySelector = {};
      recent.forEach(m => {
        const sel = m.target && m.target.selector;
        if (sel) bySelector[sel] = (bySelector[sel] || 0) + 1;
      });
      return Object.entries(bySelector).sort((a,b) => b[1] - a[1]).slice(0, 5);
    });
  })()
`}

Two seconds of watching an idle page should return nearly nothing. When it returns [["div.search-results", 214], ["span.result-count", 214]], the agent knows which subtree is thrashing and at what rate — without React DevTools, without instrumenting a single component. The same data lands in the proxy traffic log as mutation entries, so proxylog {proxy_id: "app", types: ["mutation"]} gives the history after the fact.

The severe cases arrive on their own: Maximum update depth exceeded is a thrown error, so it lands in the incident inbox with a stack trace before anyone asks.

Reproduce the classic. A search component derives a filter object in render and passes it to an effect:

function Search() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);
  const options = { caseSensitive: false, prefix: query };   // new object every render

  useEffect(() => {
    fetchResults(options).then(setResults);                  // runs every render
  }, [options]);                                             // options is never === options

  return <input value={query} onChange={e => setQuery(e.target.value)} />;
}

Every render creates a fresh options object; the effect sees a changed dependency; the fetch resolves and calls setResults; that renders again. Not fast enough to trip React's update-depth guard — just fast enough to hammer the API and re-render the results list continuously.

1. Confirm the churn is real with the mutation sample above. An idle page returning hundreds of mutations on the results subtree in two seconds is the storm, quantified.

2. Check the API side, because a render loop that fetches shows up as duplicate requests. The api_audit tool reads the recorded fetch/XHR buffer:

api_audit {proxy_id: "app"}
// → duplicate-request finding: GET /api/search?q=react fired 31 times in 4s with identical parameters

3. Pull the diagnostics with currentpage. If the loop is fast enough to trip React's guard you get the infinite-render-loop entry with its fix/avoid pair; if not, the mutation and API evidence has already localized it to the search subtree, and the agent reads that component instead of the whole tree.

4. Fix the cause. The dependency is unstable, so stabilize it — useMemo the options object, or depend on query directly. The avoid guidance matters here: moving options into the dependency array differently, or debouncing the fetch, changes the loop's speed rather than removing it.

5. Verify with the same instruments. Re-run the two-second mutation sample (idle page → near-zero), re-run api_audit (one request per keystroke burst instead of thirty-one). The fix is proven by the measurement that convicted the bug.

The companion bug classes surface the same way: missing-key diagnostics catch the list that re-mounts every item on reorder (state bleeding between rows is the visible symptom), and hydration-mismatch catches SSR/client divergence before anyone suppresses the warning — see the Next.js guide for the server-rendering side of that story.

Where This Fits​

Mutation churn on an idle page and the GPU frame pump from the compositor guide are cousins: both are "the page never goes quiet" bugs that JS profilers under-report, and both yield to the same discipline — measure, localize, fix, re-measure. When the re-render storm involves typed input specifically, the interaction-level view in Debugging Form Input and Binding Issues adds the keystroke-to-DOM correlation this guide doesn't need.

See Also​