Race Conditions in Asynchronous JavaScript: The Patterns That Cause Half Your Non-Deterministic Bugs

The cache returns stale data for exactly three users out of ten thousand. A WebSocket handler fires send() on a socket that was just closed. A batch job writes null into a required column because two async branches completed in the wrong order. The common thread: none of these bugs leave a clear trail. There is no exception, no error log, no crash. The system just does the wrong thing sometimes.

Race conditions in JavaScript are harder to spot than in threaded languages because the concurrency model is different. There is no shared memory corruption, no mutex contention, no deadlock. Instead, the race hides in the gap between an await and the next line, in the microtask queue ordering you did not think about, and in the assumption that two async operations will not interleave.

I have chased these bugs across production systems for years. They follow five predictable patterns. Here is each one, with code that reproduces it, and the fix that eliminates it.

Pattern 1: The Check-Then-Act Race

This is the single most common async race in JavaScript. You check a condition, await something, then act based on that condition. Between the check and the act, another invocation changes the condition.

// BUG: Two concurrent calls both pass the check, both write
async function claimTicket(ticketId: string, userId: string) {
  const ticket = await db.tickets.findUnique({ where: { id: ticketId } });

  // Both calls see `status === "available"` here
  if (ticket.status !== "available") {
    throw new Error("Already claimed");
  }

  // Both calls write "claimed" - the second one overwrites nothing useful
  await db.tickets.update({
    where: { id: ticketId },
    data: { status: "claimed", claimedBy: userId },
  });
}

Two concurrent requests line up like this:

Request A: findUnique() -> { status: "available" }
Request B: findUnique() -> { status: "available" }
Request A: update() -> status = "claimed", claimedBy = "A"
Request B: update() -> status = "claimed", claimedBy = "B"  // B's write wins

The second user silently gets the ticket. No error. No conflict. Just a bug that manifests in production under load and disappears during local testing.

The fix

Eliminate the window between check and act. The cleanest fix is a database-level atomic operation that combines check and act into one statement.

async function claimTicket(ticketId: string, userId: string) {
  const result = await db.tickets.updateMany({
    where: {
      id: ticketId,
      status: "available", // Only match available tickets
    },
    data: { status: "claimed", claimedBy: userId },
  });

  if (result.count === 0) {
    throw new Error("Ticket already claimed or not found");
  }
}

updateMany with a where clause that includes the expected state is atomic. If two calls execute concurrently, the database serializes them. Exactly one gets count === 1. The other gets count === 0 and throws.

When you cannot use a database atom (for example, when the check involves an external API call), use a distributed lock or a mutex (covered in the solutions section below).

Pattern 2: The Already-In-Flight Race

This one kills cache layers and causes thundering herds. When a cache miss happens, you start fetching the data. A second request arrives one millisecond later, sees the same cache miss, and starts the same fetch. Now your database is handling two identical queries, and both results will be written to cache, one overwriting the other.

// BUG: Every cache miss triggers a fresh database query
async function getUserProfile(userId: string): Promise<UserProfile> {
  const cached = await cache.get(`profile:${userId}`);
  if (cached) return JSON.parse(cached);

  // Two concurrent calls both reach here
  const profile = await db.users.findUnique({
    where: { id: userId },
    include: { posts: true },
  });

  // Both write to cache
  await cache.set(`profile:${userId}`, JSON.stringify(profile), "EX", 300);
  return profile;
}

Under low load, this never happens. Under high load, the database sees a spike at the start of every cache TTL window. The fix is a request coalescing pattern that deduplicates in-flight requests for the same key.

The fix

Store a promise, not just a value. When a request starts fetching a key, stash the promise. Subsequent requests for the same key await the same promise instead of starting a new fetch.

const inFlight = new Map<string, Promise<UserProfile>>();

async function getUserProfile(userId: string): Promise<UserProfile> {
  const cached = await cache.get(`profile:${userId}`);
  if (cached) return JSON.parse(cached);

  // If a request for this user is already in flight, join it
  const existing = inFlight.get(userId);
  if (existing) return existing;

  // Start the fetch and stash the promise
  const promise = db.users
    .findUnique({
      where: { id: userId },
      include: { posts: true },
    })
    .then(async (profile) => {
      await cache.set(`profile:${userId}`, JSON.stringify(profile), "EX", 300);
      return profile;
    })
    .finally(() => {
      inFlight.delete(userId);
    });

  inFlight.set(userId, promise);
  return promise;
}

Now ten concurrent requests for the same user all hit inFlight.get(userId) after the first cache miss, and all ten share the same database query result. The database sees one query instead of ten.

One edge case: if the promise rejects, you need to delete it from the map so the next request retries. The finally block handles that.

Pattern 3: The Shared State Race

This is the race condition that looks like a data integrity bug but is really an async sequencing problem. It happens when two async functions read and write the same mutable state without coordinating.

// BUG: Two invocations corrupt the shared state
class ConnectionManager {
  private connections = new Map<string, WebSocket>();
  private reconnectAttempts = new Map<string, number>();

  async handleReconnect(deviceId: string, newSocket: WebSocket) {
    // Both callers read the same starting state
    const attempts = (this.reconnectAttempts.get(deviceId) ?? 0) + 1;
    this.reconnectAttempts.set(deviceId, attempts);

    if (attempts > 5) {
      console.log(`Device ${deviceId} exceeded reconnect limit`);
      return;
    }

    // Simulate some async work (auth, rate limiting check)
    await this.verifySession(deviceId);

    // Both callers now act on possibly-stale state
    const existingSocket = this.connections.get(deviceId);
    if (existingSocket) {
      existingSocket.close();
    }
    this.connections.set(deviceId, newSocket);
  }

  private async verifySession(deviceId: string): Promise<void> {
    // Async I/O that introduces a yield point
    await new Promise((r) => setTimeout(r, 10));
  }
}

When two reconnect events arrive rapidly, the execution interleaves like this:

Call A: read attempts -> 0, set attempts -> 1
Call A: await verifySession (yield)
Call B: read attempts -> 1, set attempts -> 2
Call B: await verifySession (yield)
Call A: close old socket, set new socket
Call B: close the socket A just set, overwrite with B's socket  // Lost A's connection

The state transitions are not atomic because await introduces a yield point. Between any two await expressions, another invocation can read and mutate shared state.

The fix

Use a mutex (locking primitive) to serialize access to the critical section. JavaScript does not have a built-in mutex, but you can build one in 15 lines.

class SimpleMutex {
  private queue: (() => void)[] = [];
  private locked = false;

  async acquire(): Promise<() => void> {
    if (!this.locked) {
      this.locked = true;
      return this.release.bind(this);
    }

    return new Promise<() => void>((resolve) => {
      this.queue.push(() => {
        resolve(this.release.bind(this));
      });
    });
  }

  private release() {
    if (this.queue.length > 0) {
      const next = this.queue.shift()!;
      next();
    } else {
      this.locked = false;
    }
  }
}

Now protect the critical section:

class ConnectionManager {
  private connections = new Map<string, WebSocket>();
  private reconnectAttempts = new Map<string, number>();
  private mutex = new SimpleMutex();

  async handleReconnect(deviceId: string, newSocket: WebSocket) {
    const release = await this.mutex.acquire();
    try {
      // This entire block is now serialized
      const attempts = (this.reconnectAttempts.get(deviceId) ?? 0) + 1;
      this.reconnectAttempts.set(deviceId, attempts);

      if (attempts > 5) {
        console.log(`Device ${deviceId} exceeded reconnect limit`);
        return;
      }

      await this.verifySession(deviceId);

      const existingSocket = this.connections.get(deviceId);
      if (existingSocket) {
        existingSocket.close();
      }
      this.connections.set(deviceId, newSocket);
    } finally {
      release();
    }
  }
}

The mutex guarantees that only one caller holds the lock at a time. If verifySession takes 50ms, the second caller waits at acquire() until the first finishes. No interleaving, no corruption.

A word of caution: the mutex serializes operations on deviceId. If you use a single mutex for all device IDs, you serialize all reconnections, even for unrelated devices. That is fine for low-volume scenarios. For high throughput, use a per-key mutex:

private mutexes = new Map<string, SimpleMutex>();

async getMutex(key: string): Promise<SimpleMutex> {
  let m = this.mutexes.get(key);
  if (!m) {
    m = new SimpleMutex();
    this.mutexes.set(key, m);
  }
  return m;
}

Pattern 4: The Event Loop Timing Race

This one does not involve shared state at the application level. It is a pure async scheduling bug that happens because setTimeout and setImmediate and process.nextTick have different positions in the event loop phase diagram.

// BUG: Assumes callbacks fire in the order they were scheduled
function startHealthCheck(serviceUrl: string) {
  let healthy = false;

  setInterval(async () => {
    try {
      const response = await fetch(`${serviceUrl}/health`);
      healthy = response.ok;
    } catch {
      healthy = false;
    }
  }, 5000);

  // Called immediately after construction -- but when does it actually run?
  setTimeout(() => {
    if (!healthy) {
      console.log(`Service ${serviceUrl} is unhealthy on startup`);
    }
  }, 0);
}

The developer expects the setTimeout(fn, 0) to fire after the first health check completes. But setTimeout callbacks run in the timers phase of the event loop, while the fetch inside setInterval resolves its promise in the microtask queue. The order depends on how long the health check takes and what other timers are pending.

In practice, setTimeout(fn, 0) often fires before the first health check resolves, printing “unhealthy” even when the service is fine. This is the kind of bug that passes code review, passes unit tests, and then fires false alarms in production every fifth deployment.

The fix

Do not rely on timer ordering to sequence async work. Use explicit promise coordination instead.

function startHealthCheck(serviceUrl: string) {
  const healthy = new BehaviorSubject<boolean>(false);

  setInterval(async () => {
    try {
      const response = await fetch(`${serviceUrl}/health`);
      healthy.next(response.ok);
    } catch {
      healthy.next(false);
    }
  }, 5000);

  // Wait for the first real check result instead of guessing at timer timing
  healthy.first().subscribe((isHealthy) => {
    if (!isHealthy) {
      console.log(`Service ${serviceUrl} is unhealthy on startup`);
    }
  });
}

Or, even simpler, just await the first check explicitly:

async function startHealthCheck(serviceUrl: string) {
  // Run the first check synchronously before setting up the interval
  try {
    const response = await fetch(`${serviceUrl}/health`);
    if (!response.ok) {
      console.log(`Service ${serviceUrl} is unhealthy on startup`);
    }
  } catch {
    console.log(`Service ${serviceUrl} is unhealthy on startup`);
  }

  setInterval(async () => {
    // ... periodic checks
  }, 5000);
}

The rule of thumb: if you find yourself using setTimeout(fn, 0) to “wait for something to finish,” you are fighting the event loop instead of using promises. Replace it with an explicit promise chain.

Pattern 5: The Microtask Interleaving Race

This is the subtlest pattern. It happens when you iterate over an async generator, process a stream, or use Promise.allSettled in a loop, and the microtask queue interleaves operations in a way you did not anticipate.

// BUG: Microtask interleaving corrupts a running total
async function processOrders(orders: Order[]) {
  let totalRevenue = 0;

  // Each iteration yields to the microtask queue
  for (const order of orders) {
    const discount = await getDiscountRate(order.customerId);

    // Between the await and this line, another call could modify totalRevenue
    const lineTotal = order.amount * (1 - discount);
    totalRevenue += lineTotal;

    await saveOrderTotal(order.id, lineTotal);
  }

  return totalRevenue;
}

If processOrders is called concurrently for two different batches, the totalRevenue variable is shared across all invocations. Each await is a yield point where another invocation can read or write totalRevenue.

The fix is the same mutex pattern from Pattern 3, or better yet, eliminate the shared state entirely by making each invocation self-contained.

async function processOrders(orders: Order[]): Promise<number> {
  // No shared state - accumulate locally
  const lineTotals = await Promise.all(
    orders.map(async (order) => {
      const discount = await getDiscountRate(order.customerId);
      const lineTotal = order.amount * (1 - discount);
      await saveOrderTotal(order.id, lineTotal);
      return lineTotal;
    })
  );

  return lineTotals.reduce((sum, t) => sum + t, 0);
}

By using Promise.all with map, each order is processed in its own async context. The local lineTotal is not shared. The reduction happens after all async work is done, in a single synchronous pass.

The practical takeaway

Race conditions in JavaScript are not about threads or memory barriers. They are about the gap between an await and the next statement. Every await is a yield point where the event loop can schedule other work. If that other work mutates state your code just read, you have a race.

Here is the mental checklist to apply during code review:

• Does this function read state, await, then write state based on what it read? If yes, it has a check-then-act race. Use an atomic operation or a mutex.
• Does this function start an async operation based on a cache miss? If yes, it has an already-in-flight race. Use request coalescing.
• Does this class use instance properties that are read and written across await boundaries? If yes, it has a shared state race. Use a mutex or refactor to avoid shared state.
• Does this code use setTimeout(fn, 0) to sequence async work? If yes, it has an event loop timing race. Replace with promise chaining.
• Does this loop accumulate values across await calls? If yes, it has a microtask interleaving race. Accumulate locally and reduce at the end.

None of these fixes are complex. The mutex is 20 lines. Request coalescing is 10 lines. Atomic database writes are a where clause change. The hard part is recognizing the pattern when you see it, because race conditions do not crash your process. They just produce wrong answers under load.

A note from Yojji

Building reliable distributed systems requires engineering discipline at every layer, from the event loop to the deployment pipeline. The subtle race conditions that slip through code review are often the ones that cause the hardest-to-diagnose production incidents. Yojji is an international custom software development company that helps teams design and build systems with correctness and resilience baked in from the start. Their senior engineers specialize in the JavaScript ecosystem, cloud platforms, and production operations across Europe, the US, and the UK.