Recovery and degradation: evict state, back off on retry, fail honestly

Recovery is state eviction, not re-rendering

When a boundary catches, the subtree below it is unmounted — but the cause of the crash usually lives on: in a parent’s state, in a store, in a URL param. The crash is a symptom; the corrupted or unexpected state is the disease. So “retry” cannot mean “render the same thing again” — same state, same render, same throw, often within a single frame. Recovery means remounting the subtree with the poisoned state evicted or replaced.

react-error-boundary gives you both directions of that move:

<ErrorBoundary
  FallbackComponent={QuoteFallback}
  resetKeys={[symbol]}          // symbol changes → boundary auto-resets, subtree remounts
  onReset={() => refetchQuote()} // clear the cause along with the crash state
>
  <QuotePanel symbol={symbol} />
</ErrorBoundary>

resetKeys is the declarative direction: when any value in the array changes — the user picks another symbol, the route param updates — the boundary leaves its error state and remounts children. The crash was about the old input, so new input is the natural recovery trigger. resetErrorBoundary() (handed to the fallback) is the imperative direction: a Retry button. But pressing it only clears the boundary’s own error flag and remounts children with fresh local state — if the poison lives outside the subtree, you must also fix the cause in onReset: refetch, clear the cache entry, reset the store slice. Plain React without the library does the same thing with a key: bump key={attempt} on the subtree and React unmounts the old instance, state and all, and mounts a new one. Remounting is the point — a corrupted child’s state must die, and key identity is how React decides what dies.

Retry with backoff — or become the second outage

When you add a Retry button, you are making a distributed-systems decision on behalf of every client that will ever open this page simultaneously. Transient failures — a 503, a dropped connection, a brownout — deserve a retry. But the Hook’s incident is the standard failure mode of naive retry: thousands of clients retrying at the same fixed interval form a synchronized wave (the thundering retry), and the load you add arrives precisely when the service is least able to absorb it. Client-side retry is a distributed-systems decision made in UI code. The discipline is the same as on the backend:

async function retryFetch(url, { tries = 3, base = 1000, cap = 30_000 } = {}) {
  for (let attempt = 0; ; attempt++) {
    try {
      const res = await fetch(url);
      if (res.status >= 500) throw new Error("HTTP " + res.status);
      return res;
    } catch (err) {
      if (attempt + 1 >= tries) throw err;             // budget exhausted → boundary
      const delay = Math.min(cap, base * 2 ** attempt); // 1s, 2s, 4s … capped
      await new Promise((r) => setTimeout(r, delay + Math.random() * delay)); // jitter
    }
  }
}

Three rules hide in those ten lines. Exponential backoff spreads the wave over time — 1s, 2s, 4s instead of a fixed metronome. Jitter desynchronizes the clients — without the random term, thirty thousand dashboards that failed together retry together forever. A retry budget ends the story: after the budget, throw to the boundary and let a human-paced action (the Retry button) become the next attempt — a user clicking is naturally rate-limited and naturally jittered. And only retry what is plausibly transient: a 503 yes, a 400 from a malformed request no — retrying a deterministic failure is a tight loop with extra steps.

Partial degradation: error budgets, applied to pixels

A widget boundary does more than catch — it converts a crash into a degraded mode while the rest of the page lives. That is error-budget thinking applied to UI: not every region of the screen has the same availability requirement, so not every region should fail with the same blast radius. A recommendations rail can fail to an empty slot and nobody loses money. A quotes widget can show the last successful tick, visibly marked stale, which beats both a spinner and a hole. The page-level question becomes: which regions are decorative, which are degradable with stale data, and which are integrity-critical?

The fallback itself owes the user three honesty rules. Say what broke at the user’s granularity — “Quotes are unavailable” beats “Something went wrong”, and both beat an infinite spinner, which is a lie about progress. Offer the real next action — a Retry wired through reset-plus-cause-eviction, not a decorative one. And keep the exits alive — navigation, the rest of the page, the data the user already entered. A fallback that traps the user is a second failure on top of the first.

Then there is the case where partial survival is the wrong goal. If the broken thing is integrity-critical — the auth context that decides whose data renders, the payment step that decides how much gets charged, the cart total feeding the order — degrading politely around it risks showing user A the session of user B, or charging against a stale total. There you fail the page intentionally: full-route fallback, no cheerful “some features may be unavailable”. Availability is a feature; correctness is the product.