Code review is, at its core, a human reading code and simulating it in their head. That simulation is single-threaded. A reviewer traces through what happens if this call succeeds, then what happens if it fails, one path at a time, and the code usually looks correct under both. What a reviewer can’t simulate well is what happens when a hundred and fifty of these paths are running at once, interleaved in an order nobody chose, against infrastructure that is itself failing partway through. That’s not a matter of the reviewer not being careful enough. It’s a different failure class entirely, one that only exists once you introduce real concurrency and real partial failure, and reading code carefully doesn’t put either of those things in front of you.
A bug that looked correct until three services were down
aws-llm-inference-platform builds a chat response by making three independent upstream calls at once: pulling RAG context from a vector store, chat history from a database, and results from a web search tool. The original version combined them with Promise.all:
const [ragResult, histResult, webResult] = await Promise.all([...]);Read in isolation, this is fine. Three async calls, run them concurrently, wait for all three, proceed. A reviewer looking at this line has no reason to flag it, Promise.all is the standard way to run independent async work concurrently, and the code compiles, typechecks, and returns the right shape when all three calls succeed. The bug only exists in the branch where the vector store call fails and the other two succeed. Promise.all rejects as soon as any one of its promises rejects, discarding the results of the ones that already resolved. A single Pinecone outage meant every chat request lost its conversation history and web search results too, not just RAG context, for as long as the vector store was unhappy. Nothing about the code looks wrong until you actually run it with one dependency down while load is hitting the other two, which is not a scenario code review puts you in.
The fix swaps in Promise.allSettled, which resolves once all three promises have settled, successfully or not, and lets each result be checked independently:
// Build prompt with RAG context + web search + recent chat history.
// These three are independent upstream calls (Pinecone, DynamoDB, web
// search) -- use allSettled, not all, so one failing (e.g. a Pinecone
// outage) doesn't silently discard the other two, which may have
// succeeded.
const [ragResult, histResult, webResult] = await Promise.allSettled([...]);
if (ragResult.status === "fulfilled") {
ragContext = ragResult.value;
} else {
console.error("RAG context unavailable, continuing without it:", ragResult.reason);
}Now a Pinecone outage degrades one input to the prompt instead of the whole request. What matters here has nothing to do with the specific API: the bug was invisible to inspection and only became visible under partial failure, which is exactly the condition real production traffic eventually produces and a code diff never does.
A race that only shows up at 150 concurrent threads
flash-sale-system is built to sell a fixed pool of tickets without overselling under concurrent demand, and it ships its own chaos simulator to prove the concurrency-safe approach actually is safe, rather than asserting it in a comment. The /simulator page runs two implementations side by side against the same starting inventory: a naive read-check-write (“read the counter, check if enough tickets remain, decrement it”) and the production approach, a Redis Lua script that performs the check and decrement as a single atomic operation because Redis executes Lua scripts on one thread with no interleaving possible.
At low concurrency, both look correct. The bug in read-check-write is a classic time-of-check-to-time-of-use gap, two requests can both read the counter before either has written its decrement, both see enough inventory, and both proceed to sell a ticket that only existed once. That gap is nanoseconds wide. A reviewer reading read, check, write as three sequential lines has no way to see the gap, because on the page those are just three lines that execute in order for the one request they’re picturing. The gap only opens up when a second request’s read lands inside the first request’s check-to-write window, which requires actual concurrent requests, not a single mental walkthrough.
The simulator forces that scenario by running 150 concurrent threads against both implementations at once. System A, the naive version, drifts, the final counter doesn’t match what should have been sold, meaning the same inventory got sold more than once. System B, the Lua script version, locks at exactly zero with full integrity. The two implementations are both a handful of lines, both readable, both would pass a code review that didn’t specifically ask “what happens if two of these run at the exact same instant.” The only thing that separates them, correct under load versus silently overselling under load, is invisible until you actually put load on them.
The general point
Code review is good at catching bugs a reviewer can picture: wrong variable, missing null check, off-by-one, a condition that’s backwards. It’s structurally bad at catching bugs that only exist in the interaction between multiple things happening at once, because a human reading code top to bottom is simulating one execution, not many overlapping ones. Races, partial failures, and resource exhaustion under load are not “harder to spot” versions of the same bug class review already catches, they’re a different class that doesn’t exist at all until concurrency or failure is actually introduced. That’s what chaos and load testing are for: not finding more of the bugs review would eventually find with enough scrutiny, but finding the bugs that no amount of reading was ever going to surface, because the code was never wrong in the scenario the reviewer was picturing.