detecting-race-conditions

# Detecting race conditions Race bugs don't live in one line - they live in the *gap* between two operations that another actor can slip through. There's no tainted value to trace and no single sink to grep; you find them by asking what state is shared, what runs concurrently, and where a window opens between deciding something and acting on it. This skill covers the recurring shapes and how to confirm a real window. ## When to use - Multithreaded / async / multiprocess code, or a shared resource (DB row, cache, counter, file, in-memory map) touched by concurrent requests. - A "check then act" sequence where the check's truth can expire before the act: balance/quota checks, auth-then-use, uniqueness/dedup guards, file existence checks, one-time tokens. ## Scope check Authorized source only. If you can't name the authorization, stop. ## The shapes and how to confirm each Confirmation of a race is an **interleaving witness**: two concrete operation orders where one is safe and the other, achievable by an attacker, is not. 1. **TOCTOU (time-of-check to time-of-use).** State is validated, then used, and it can change in between. Classic filesystem form: `access(path)` / `stat(path)` then `open(path)` - a symlink swap in the window redirects the open. General form: any `check(x); … ; use(x)` where `x` (or what it names) is mutable by another actor in the gap. Confirm: identify the shared thing, show a writer that can change it between check and use. 2...