Can't Perform State Update on Unmounted Component Fix

You click into a user profile, click back before it loads, and the console scolds you: can't perform a React state update on an unmounted component. Nothing visibly breaks, so it's tempting to shrug. But that message is describing a real leak — work you paid for that delivers to nobody.

The mechanics are simple. Your effect fires a fetch, the user navigates away, the component unmounts, and then the promise resolves. Its .then callback still holds a reference to the state setter, so it calls setState on a component React already tore down. Before React 18 you got the warning. After React 18 you get silence and the same wasted work.

This bites hardest in exactly the apps you'd expect: search-as-you-type, tabbed dashboards, paginated tables, and any route that fetches on mount. Fast navigation turns every one of those into a race between unmount and resolution, and the loser writes state into the void.

This guide shows the full picture. You'll learn why async outlives unmount, how AbortController and effect cleanup cancel it for real, why the isMounted flag only hides the evidence, and what React 18's removed warning means for your debugging habits.

Why Async Resolving After Unmount Triggers the Warning

The warning fires on a strict timeline. Your component mounts, its effect starts async work — a fetch, a timeout, a subscription — and before that work finishes, the user navigates away. React unmounts the component, tears down its state hooks, and moves on. Then the promise resolves and the .then callback runs, calling a state setter that no longer has a live component behind it.

That setter isn't magic. It's a closure captured when the effect ran, holding a reference to the component's hook cell. After unmount, calling it can't trigger a re-render because there's nothing to render. Before React 18, React detected this and logged the warning. It never crashed your app, which is exactly why teams ignored it — the failure mode is wasted work and potential stale writes, not an exception.

Where this turns from waste into corruption is the remount case. The user navigates back, a fresh instance mounts with fresh state, and then the old request resolves and writes its stale payload into the new instance's state if the closure is shared through a store or a lifted setter. Search boxes, autocomplete, and tabbed dashboards hit this constantly because their requests overlap by design.

The takeaway is structural: any async work started in an effect must be tied to that effect's lifetime. If the effect can be torn down before the work finishes — and in React, it always can — you need a cancellation path. The next sections build exactly that.

AbortController Cancels Fetch When the Component Unmounts

AbortController is the web platform's standard cancellation primitive, and fetch understands it natively. You create a controller, hand its signal to fetch, and call abort() when the work is no longer wanted. The pending fetch rejects with an error whose name is AbortError, which you catch and deliberately ignore — it isn't a failure, it's a successful cancellation.

The pattern slots perfectly into useEffect. Create the controller inside the effect so each run gets its own, pass the signal to every fetch that run starts, and return a cleanup function that aborts. When the component unmounts — or when dependencies change and React re-runs the effect — the previous controller aborts, the old request dies, and only the current run's response can reach setState.

Two details trip people up. First, abort() rejects the promise, so you must handle AbortError or you'll trade one console warning for an unhandled rejection. Check err.name === 'AbortError' and return early. Second, libraries differ: axios uses the same signal option in recent versions, while older code uses CancelToken. Check your HTTP client's docs, but the shape is identical — a token in, a cancel call in cleanup.

This isn't just about silence. Aborting actually frees the socket, drops the response bytes, and lets the closure garbage-collect. It's the difference between muting a fire alarm and putting out the fire.

import { useEffect, useState } from 'react';

export function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [error, setError] = useState(null);

  useEffect(() => {
    const controller = new AbortController();

    async function load() {
      try {
        const res = await fetch('/api/users/' + userId, {
          signal: controller.signal
        });
        if (!res.ok) throw new Error('request failed: ' + res.status);
        setUser(await res.json());
      } catch (err) {
        if (err.name === 'AbortError') return; // unmounted: expected
        setError(err.message);
      }
    }

    load();
    return () => controller.abort(); // cancel on unmount or userId change
  }, [userId]);

  if (error) return <p>Failed: {error}</p>;
  if (!user) return <p>Loading…</p>;
  return <h1>{user.name}</h1>;
}

useEffect Cleanup Is the Only Safe Place to Cancel Work

The cleanup function is the only code React guarantees to run when an effect's lifetime ends. It runs before the effect re-runs on dependency changes and when the component unmounts. That makes it the single correct place to release everything the effect acquired: abort controllers, timer handles, subscription handles, and event listeners.

The most common mistake is splitting ownership — starting work in the effect body but cleaning it in a different effect, a click handler, or not at all. When ownership splits, at least one path skips cleanup. Keep it adjacent: the line that creates the resource and the line that releases it should live in the same effect, ideally within ten lines of each other so review catches gaps.

Cleanup also runs in StrictMode development double-invocation, which is a feature, not a bug. React mounts, cleans up, and re-runs effects to surface missing cleanup early. If your effect can't survive that cycle — if the second run doubles subscriptions or the cleanup crashes — production navigation will break it too. Treat StrictMode complaints as free bug reports.

Apply the same discipline beyond fetch. setTimeout needs clearTimeout, setInterval needs clearInterval, addEventListener needs removeEventListener, and socket.subscribe needs unsubscribe. Whatever verb opened the resource, its opposite belongs in the return statement.

import { useEffect, useState } from 'react';

export function LiveFeed({ topic }) {
  const [items, setItems] = useState([]);

  useEffect(() => {
    const controller = new AbortController();
    const timer = setTimeout(() => {
      fetch('/api/feed?topic=' + topic, { signal: controller.signal })
        .then((r) => r.json())
        .then(setItems)
        .catch((err) => {
          if (err.name !== 'AbortError') console.error(err);
        });
    }, 500);

    return () => {
      clearTimeout(timer); // cancel the delayed start
      controller.abort(); // cancel the fetch itself
    };
  }, [topic]);

  return (
    <ul>
      {items.map((i) => <li key={i.id}>{i.title}</li>)}
    </ul>
  );
}

Why the isMounted Flag Is an Anti-Pattern

The isMounted pattern looks like this: a ref set to true on mount and false in cleanup, with every setState wrapped in if (mountedRef.current). The console goes quiet, the ticket gets closed, and the leak continues. The fetch still crosses the network, the timer still fires, the subscription still pushes — you've only taught the callback to stay silent about it.

Worse, the flag actively hides races. Two overlapping requests both check the same ref, both find it true, and both write state in arrival order. The guard was never designed for ordering; it only knows mounted versus unmounted. So the stale response still overwrites the fresh one, and because the warning is gone, nobody investigates.

There's a subtler cost: the ref keeps the closure's world alive. The .then callback holds the ref, the ref lives on the component instance, and the instance's context — props, large payloads, store references — can't garbage-collect until the request settles. On route churn this adds up to real megabytes, exactly the growth teams chase with heap snapshots.

The React team removed the warning in React 18 partly for this reason: it trained developers to add flags instead of cleanup. The recommended fix hasn't changed — cancel the work itself. When nothing is left running after unmount, there's nothing to guard, and the flag becomes dead code you can delete.

React 18 Removed the Warning, Not the Memory Leak

React 18 removed the unmounted-component warning outright. If you upgrade and the console goes quiet, that's the framework change, not proof your effects are clean. The underlying behavior — promises resolving into dead closures — works exactly as before, minus the announcement.

The removal happened because the warning misfired and misled. It fired for harmless cases like setting state after a component unmounted during a Suspense transition, and it pushed developers toward isMounted flags that hid real leaks. The React team decided a warning that teaches the wrong fix is worse than no warning, and they were right.

So where does the signal come from now? Your own discipline. Test navigation under throttled network and watch for post-unmount resolutions. Take heap snapshots across route churn and confirm retained size stays flat. Add a lint rule against mounted refs. These checks replace the console message with something better: verification instead of vibes.

There's an upside. Without the warning to chase, teams stop playing whack-a-mole with setters and start designing cancellation properly — AbortController per effect, cleanup per resource, ordering per request stream. The apps that do this are quieter than React 17 apps ever were, and their quiet is earned.

import { useEffect, useState } from 'react';

export function SearchBox() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);

  useEffect(() => {
    if (!query) { setResults([]); return; }
    const controller = new AbortController();
    const id = setTimeout(() => {
      fetch('/api/search?q=' + encodeURIComponent(query), {
        signal: controller.signal
      })
        .then((r) => r.json())
        .then(setResults)
        .catch((err) => {
          if (err.name !== 'AbortError') console.error(err);
        });
    }, 120);

    return () => {
      clearTimeout(id);
      controller.abort();
    };
  }, [query]);

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

Race Conditions When Two Requests Fight Over One State

Unmounts get the headlines, but overlapping requests cause more user-visible damage. Type a three-letter query fast and you fire three requests. The network doesn't guarantee order, so the one-letter response can arrive last and overwrite the three-letter results. The user sees answers to a question they stopped asking.

Cleanup alone doesn't solve this, because all three requests belong to the same mounted component — no unmount happens between keystrokes. What solves it is ordering: each effect run aborts the previous run's request when dependencies change. React runs the old cleanup before the new effect, so the previous controller aborts exactly when the next query starts. Only the newest request survives.

Abort isn't always enough, though. Cached responses, non-abortable clients, or requests that already reached the server can still resolve out of order. That's where the sequence counter helps: stamp each request with an incrementing number and let only the highest number write state. Belt and suspenders — abort what you can, ignore what you can't.

Add debouncing to cut volume, not to fix ordering. A 100–200 ms delay collapses a burst of keystrokes into one request, which saves backend cost. But a debounced request can still race the next one, so keep the abort and the sequence check regardless. Volume control and correctness are separate jobs.

import { useEffect, useRef, useState } from 'react';

export function Typeahead({ query }) {
  const [hits, setHits] = useState([]);
  const latest = useRef(0);

  useEffect(() => {
    if (!query) { setHits([]); return; }
    const seq = ++latest.current;
    const controller = new AbortController();

    fetch('/api/search?q=' + encodeURIComponent(query), {
      signal: controller.signal
    })
      .then((r) => r.json())
      .then((data) => {
        if (seq === latest.current) setHits(data); // newest wins
      })
      .catch((err) => {
        if (err.name !== 'AbortError') console.error(err);
      });

    return () => controller.abort();
  }, [query]);

  return <ul>{hits.map((h) => <li key={h.id}>{h.name}</li>)}</ul>;
}