How do you safely handle async work and race conditions inside effects?

Q: How do you safely handle async work and race conditions inside effects?

**Target Audience:** Engineers preparing for senior React interviews — assumes effects and promises. **Difficulty:** Hard > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . This is the deep hazard taxonomy; handling async operations is the introduction, and the race-condition measurement quoted in section 3 comes from there. ## 1. Why This Even Matters — A Story First A relay runner takes the baton and starts running. Halfway round, the race is called off and a new race begins with a different runner. Nobody told the first runner — they finish their lap and hand the baton to the finish judge, who records it. Every await is a runner mid-lap. The code before it ran in one world; the code after it resumes in a world that may have moved on. Safe async code in effects is entirely about checking, at every resumption, whet

The problem

Question presented to candidate: "Give me the full picture of doing async work inside an effect safely — every hazard you would guard against."

What a strong answer should cover:

Why cleanup ordering is the foundation: it runs before the next effect, so a flag set there is guaranteed to beat the previous run's continuation.
Race conditions: responses arriving out of order. A slow earlier request can overwrite a newer one, silently.
Two guards, ranked: AbortController (cancels the request and frees the connection) then a cancellation flag (only ignores the result).
Every await is a resumption point. The component may have unmounted or the dependency changed by the time each one resolves — so guard after each await, not only the first.
The effect callback must not be async — it would return a promise where React expects cleanup.
StrictMode runs setup, cleanup, setup, so an async effect must tolerate being started, aborted, and started again.
Stale closures interact with this: an async continuation reads values captured at its own render.
Swallow AbortError, and never leave the error state unhandled.
The honest recommendation: this is a lot of invariants to maintain by hand, which is the argument for a query library.

Clarifying questions expected:

"Is the work triggered by rendering, or by a user action?" — the latter belongs in a handler.
"Can the underlying API be aborted, or only ignored?"

Code / implementation expected: Yes — a multi-await sequence with a guard after each step.

react
effects
async

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for senior React interviews — assumes effects and promises. Difficulty: Hard

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. This is the deep hazard taxonomy; handling async operations is the introduction, and the race-condition measurement quoted in section 3 comes from there.

1. Why This Even Matters — A Story First

A relay runner takes the baton and starts running. Halfway round, the race is called off and a new race begins with a different runner. Nobody told the first runner — they finish their lap and hand the baton to the finish judge, who records it.

Every await is a runner mid-lap. The code before it ran in one world; the code after it resumes in a world that may have moved on. Safe async code in effects is entirely about checking, at every resumption, whether the

The solution is hidden so you can try first

6 min read · 11 sections

Try it in the playground

Open any example in the playground to run and change it.

ReactA multi-step async effect with a guard after every await

Open in playground

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

// Two dependent steps, both slow, so you can change the id mid-flight.
const wait = (ms, v) => new Promise((r) => setTimeout(() => r(v), ms));
async function getUser(id, signal) {
  await abortable(700, signal);
  return { id, name: "User " + id };
}
async function getOrders(userId, signal) {
  await abortable(700, signal);
  return [userId * 10, userId * 10 + 1];
}
function abortable(ms, signal) {
  return new Promise((resolve, reject) => {
    const t = setTimeout(resolve, ms);
    signal?.addEventListener("abort", () => {
      clearTimeout(t);
      const e = new Error("aborted"); e.name = "AbortError"; reject(e);
    });
  });
}

function Profile({ id, log }) {
  const [state, setState] = useState({ step: "idle", user: null, orders: null, error: null });

  useEffect(() => {
    const controller = new AbortController();
    setState({ step: "loading user", user: null, orders: null, error: null });
    log("start id=" + id);

    // The callback stays synchronous; the async work lives in here.
    (async () => {
      try {
        const user = await getUser(id, controller.signal);
        // CHECKPOINT 1 — the dependency may have changed during that await.
        if (controller.signal.aborted) return;
        setState((s) => ({ ...s, step: "loading orders", user }));

        const orders = await getOrders(user.id, controller.signal);
        // CHECKPOINT 2 — and again during this one.
        if (controller.signal.aborted) return;
        setState({ step: "done", user, orders, error: null });
        log("finished id=" + id);
      } catch (e) {
        if (e.name === "AbortError") { log("aborted id=" + id); return; }
        setState({ step: "error", user: null, orders: null, error: e.message });
      }
    })();

    // Cleanup runs BEFORE the next effect — this is the whole guarantee.
    return () => controller.abort();
  }, [id, log]);

  return (
    <div style={{ border: "1px solid #ddd", borderRadius: 8, padding: 12 }}>
      <p style={{ margin: 0 }}>
        asked for <strong>{id}</strong> · step: <strong>{state.step}</strong>
      </p>
      {state.user && (
        <p style={{ margin: "4px 0", color: state.user.id !== id ? "crimson" : "#161" }}>
          {state.user.name}{state.orders ? " · orders " + state.orders.join(", ") : ""}
        </p>
      )}
      {state.error && <p style={{ color: "crimson" }}>{state.error}</p>}
    </div>
  );
}

export default function App() {
  const [id, setId] = useState(1);
  const [log, setLog] = useState([]);
  const push = useRef((line) => setLog((l) => [...l, line])).current;

  return (
    <div style={{ padding: 24, fontFamily: "system-ui", lineHeight: 1.6 }}>
      <Profile id={id} log={push} />
      <p>
        {[1, 2, 3].map((n) => (
          <button key={n} onClick={() => setId(n)} style={{ marginRight: 6 }}>user {n}</button>
        ))}
        <button onClick={() => setLog([])}>clear log</button>
      </p>
      <pre style={{ background: "#f6f6f6", padding: 10, borderRadius: 6, fontSize: 12, maxHeight: 150, overflow: "auto" }}>
        {log.length ? log.join("\n") : "(nothing yet)"}
      </pre>
      <p style={{ color: "#666", fontSize: 13 }}>
        Click user 1, then user 2 while it is still loading. The log shows the
        first run aborted rather than finishing — the checkpoints stop it
        writing state for a user you have already navigated away from.
      </p>
    </div>
  );
}

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.