Eye Training · Shared State and Races

Every await is a door. While your code waits, someone else walks through it and changes what you read.

Part 2 · Surface 18. Bug counts are hidden and some snippets are clean. See Start Here for how to use these drills.

J · The basics

M · Three years in, these should jump out

S · Where seniors stand out

What your eye checks

Whenever code reads something, then awaits, then acts on what it read, ask:

1. Who else could change it during the await? Another request, another tab, another instance, a retry.
2. Is the check in the same atomic step as the write? A conditional UPDATE … WHERE, a unique constraint, SELECT … FOR UPDATE. A separate read is a gap.
3. Is the arithmetic done by the database? likes = likes + 1, not post.likes + 1 written back.
4. Where does this state live? A module variable is shared by every request; an in-process Set or lock exists once per instance.
5. Is this a copy or a shared object? { ...obj } copies one level.
6. Can it run twice? Double clicks, retries, webhook redelivery. Make it idempotent with keys and unique inserts.
7. Which response wins? Out-of-order responses overwrite newer state unless you abort or check that the result is still wanted.
8. Do concurrent callers each start the same work? Share one in-flight promise.

Tells

Go deeper

• Race Conditions: interleavings, lost updates and stale responses, with a simulation
• L4 · Concurrency and Time: the same races in bigger codebases
• Previous surface: Caching and memoization · Next: Values, equality and numbers