Reproducing race conditions

Concurrency & Timing Reproduction

When to Use

Use when a bug occurs "only sometimes," under rapid double-clicks, parallel webhook deliveries, concurrent worker jobs, async stream cancellations, or database transaction contention.

Replace Random sleep() Guessing with Deterministic Interleaving

A race condition happens when Operation $A$ and Operation $B$ overlap in a critical window $[t_1, t_2]$. Using random setTimeout delays makes tests slow and flaky. Instead, widen or control the critical window deterministically:

1. Check-Then-Act (TOCTOU) & Double-Submission Races

Scenario: Two concurrent requests pass the if (!exists) or if (balance >= amount) check before either writes its update.

• Deterministic Barrier Technique:
  1. Launch Request $A$ and Request $B$ concurrently (Promise.all([reqA(), reqB()])).
  2. Where supported by test hooks or mock/spy wrappers around the I/O step between the read check and the write commit, pause both fibers at a shared Latch / Barrier until both have completed the read check, then release both to execute the write simultaneously.
  3. Assert that the invariant (e.g., duplicate record created, negative balance, lost update, or unhandled unique-constraint 500 crash) is triggered 100% of the time.

2. Async Completion Ordering & Stale-State Overwrites

Scenario: Operation $A$ starts before Operation $B$, but $A$ finishes after $B$ and overwrites newer state with stale data.

• Controlled Deferred Resolution:
  • Intercept the underlying network/storage promise for call $A$ and call $B$ using controllable Deferred promises:

    const callA = createDeferred();
    const callB = createDeferred();
    // Trigger A, then trigger B
    // Resolve B first: callB.resolve(freshData);
    // Resolve A second: callA.resolve(staleData);
    

  • This reproduces out-of-order async bugs in < 10ms with 100% determinism.

3. Database Lock Contention, Deadlocks & Queue Leases

• Deadlock Reproduction ($A \to B$ vs. $B \to A$): Open two concurrent transactions; Transaction 1 locks Row $X$, Transaction 2 locks Row $Y$, then Transaction 1 requests Row $Y$ while Transaction 2 requests Row $X$.
• Queue Stalled-Lock Expiry: Configure a short lease/visibility timeout in the test (e.g., 100ms) while a worker job is held on a 250ms barrier, proving a second worker picks up the in-flight job concurrently.

4. Bounded Stress Harness for Native / Multi-Threaded Races

When fine-grained promise interception is impossible (e.g., OS filesystem races, multi-process SQLite SQLITE_BUSY, Rust thread races):

• Use tools like loom (for Rust atomics/mutexes) or a bounded parallel worker burst (N = 20–50 concurrent operations over a tight loop with a hard timeout), recording the exact failure ratio (k / N runs).