Sometimes It's Wrong Is What A Race Condition Looks Like From Outside

The bug that only shows up when nobody's watching

A support ticket comes in. "Sometimes the order total is wrong." No steps to reproduce, no pattern anyone can point to. You stare at the checkout code for twenty minutes, it looks fine, and you close the tab telling yourself it was probably a fluke.

It was a race condition, not a fluke, and "sometimes it's wrong" is exactly what one looks like from the outside. Two operations that assume they'll run in a particular order, occasionally don't, and the bug only shows its face on the runs where the timing lines up wrong.

Race conditions are miserable specifically because they resist the normal debugging loop: reproduce, isolate, fix, verify. You can't reproduce them on demand, which makes every other step harder too.

The Isolate a race condition from a bug report that just says 'sometimes it's wrong' prompt exists for exactly this moment: a vague symptom, shared state somewhere in the code, and no idea yet which line is actually the problem.

How it works

Instead of asking you to already know where the bug is, the prompt starts from what you do have: the vague report, and a rough description of the code path. It walks the LLM through finding every point where two operations could interleave in an order nobody planned for, a read-then-write on a shared variable with no lock, two async calls racing to finish, a check-then-act gap where something else can slip in between the check and the act.

For each candidate it asks what the bad outcome would actually look like if that specific interleaving happened, then checks that against the symptom in the bug report. That step matters more than it sounds. A codebase can have several places where a race is theoretically possible, and only one of them produces the exact wrong number a customer actually saw. Chasing the wrong candidate wastes a day; matching the outcome to the report narrows it fast.

Once a real candidate turns up, the prompt asks for a way to force it: add artificial delay at the suspected point, fire a batch of concurrent requests at the same shared state, whatever increases the odds of triggering the race in a test environment instead of waiting for production to serve it up again at random. The suggested fix goes past "add a lock" and asks for the pattern that matches this specific interleaving, a lock, an atomic operation, restructuring around the shared state, or an idempotency check, because the wrong fix for the wrong shape of race condition just moves the bug somewhere less visible.

A worked example

Say the report is: "Every so often, a customer gets charged twice for the same order." No steps to reproduce, happens maybe once every few hundred checkouts.

You know the checkout flow checks whether an order's already been charged before firing the payment call, then updates the order's status once payment succeeds. You feed that description into the prompt along with the report.

The output walks straight to the obvious suspect: a check-then-act gap. The code checks "has this order been charged," and if two requests for the same order land close enough together, both can pass that check before either one updates the status, and both fire the payment call. It's not a rare edge case at all, it's the default outcome of a network retry, a double-click, or a webhook firing twice, none of which are unusual in a real checkout flow.

The suggested reproduction: fire two concurrent requests against the same order ID in a test environment and watch the charge count. The suggested fix: not a broader lock around the whole checkout function, which would just slow every request down waiting on every other one, but a unique constraint or idempotency key tied to the order ID at the database level, so a second charge attempt for the same order fails cleanly instead of succeeding twice without anyone noticing. That's a fix that matches the actual shape of the bug, not a generic "add locking" that would have worked but cost real throughput to get there.

Why this beats staring at the code

The real value is the order of operations, more than any single fact the prompt surfaces that you couldn't have found on your own eventually. Left alone, most people staring at a "sometimes it's wrong" ticket start reading code top to bottom hoping something jumps out, which works eventually but burns hours on code that was never the problem. Working backward from the actual bad outcome to the specific interleaving that produces it gets you to the right line of code far faster, and it gives you a genuine test, not a hope, that the fix actually addresses what happened.

It also protects against the second failure mode: shipping a fix, having the bug not recur for a week, and declaring victory on a bug that was intermittent to begin with and might just not have rolled the dice again yet. A fix that comes with a deliberate way to force the race is a fix you can actually verify, not one you're just hoping stays fixed.

How to use it

1. Paste the bug report exactly as you received it, vague wording and all, along with a rough description of the code path and whether shared state is involved.
2. Work through the candidate interleavings the prompt surfaces and match each one against the actual symptom before picking where to dig in.
3. Use the suggested reproduction technique to force the race in a test environment, confirm the fix actually stops it, not just that the bug went quiet for a while.

If race conditions keep showing up in your bug queue, the rest of this week's debugging batch covers the wider intermittent-bug problem too, worth a look if "sometimes" is a word that shows up in your tickets more often than you'd like.