Understanding React's behavior under the hood when an exception occurs

[GlennMiller1991]

Hello. Please help me understand why in the last two versions at least (v18, v19) when an exception occurs in the rendering thread, React tries to re-render the tree exactly four times? Not two times, which seems logical, but exactly four.

I understand that this behavior should not be analyzed in principle, since react provides a way to handle these exceptions, so this is more of a research question and I hope you can shed some light on this behavior.

Here is the code that illustrates this behavior. Logging works exactly four times with different code modifications.:

export function App() { 
  return <Comp/>
}

export const Comp = () => {

  const [state, setState] = useState(() => {
    console.log('create instance');
    return 1;
  });

  const flag = true;
  if (flag)
    throw new Error;

  return (
    <div>

    </div>
  )
}

[KeviNKvN-X]

React retries 4 times because it implements a retry strategy for transient errors. It's not 2 because 4 attempts provide better balance between recovering from temporary errors (race conditions, inconsistent state) and performance. This is an internal detail of the Fiber reconciler, your useState executes 4 times because each retry recreates the component.

[sravan-kumar-ta]

Hi! Interesting observation — and great question.

This behavior relates to React's error recovery mechanism in concurrent mode (introduced in v18+). When an exception occurs during rendering, React may attempt to recover and retry rendering the component subtree, depending on the error boundary setup and internal heuristics.

The "four retries" you're seeing is likely a result of React's internal render phase retry logic, where it progressively backs off or switches rendering lanes to attempt a stable update. This behavior isn't officially documented (and may change across versions), but it aligns with what others have noticed in dev mode:

• React may retry rendering multiple times to see if the error resolves.
• In development mode, retries help surface issues and ensure error boundaries catch errors predictably.
• The retry count can differ between dev and production builds.

So while four retries may feel "too specific," it's likely an implementation detail rather than a strict rule.

Hope this helps!

[varuntyagii]

🤔 Why does React re-render exactly four times after a rendering error in recent versions (v18, v19)?

Hello! Great question. This behavior is quite interesting and mostly falls into React's internal design for error recovery and development debugging experience.

Here's why:

1. Error Recovery Testing
   React is testing whether the error is a one-time issue or consistent across renders. It’s helpful in development because it ensures that the error is reproducible and not caused by some flaky side effect or race condition.

2. Strict Mode Double Rendering
   In Strict Mode, React already renders components twice intentionally (only in dev mode). This helps detect side effects and unsafe operations. If your component throws an error during one of these renders, React might retry a few times as part of its internal dev tools behavior.

3. No Impact on Production
   This retry logic does not happen in production builds. In production, if your component throws during rendering, the error is thrown once and React immediately renders the error boundary (if present) or crashes the app.

4. Error Boundaries Can Stop It
   If you wrap the component in an Error Boundary, React won't retry the rendering 4 times. Instead, it catches the error and renders the fallback UI right away.

Example:

function Comp() {
  throw new Error("Render failed");
}

function App() {
  return (
    <div>
      <Comp />
    </div>
  );
}