Two requests, one "already claimed?" check, two credits.
The fix is not another check. It is moving the decision where it cannot race.
- The track
- Writes code
- The rep
- About thirty seconds
- Published
- September 2, 2026
The Exhibit
The closing argument of this series, in evidence: one of the field's largest meta-analyses, 272 controlled comparisons across 118 articles, found retrieval practice beats restudying by about half a standard deviation (g = 0.51) and beats no practice by nearly a full one. The study.
Set that against issue 01: the speed is real, but it is borrowed against a craft you stop practicing. Speed you can feel; the erosion underneath you cannot, until you reach for the skill and it is not there. Durable capability is the thing that actually compounds. Across a whole series of failure modes, the same cheap habit (retrieve, do not just receive) is what defends the one asset the tools cannot give you: your own model of the systems you run.
The study
Comprehension Debt
Comprehension debt: the gap between what gets shipped and what the team can still reason about.
By now the pattern is familiar: output that looks fine while understanding quietly leaves, and one defense underneath all of it, pull the knowledge back out, briefly and often, until you can produce it cold. So, one last bug, the kind that only exists for people who still hold the model.
The idea
The Rep
Thirty seconds:
A "claim free credit" endpoint reads whether the user has claimed, and if not, writes the credit. During a promo, some users get two. What is the bug and where does the fix belong?
The answer
A race condition on a check-then-act sequence. Two concurrent requests both run the "already claimed?" read before either commits the write, both see "not claimed," and both grant the credit. The window is small, which is why it only shows up under the promo's concurrency. Adding another application-level check just shrinks the window; it does not close it, because there is always a gap between the read and the write. The fix belongs in the database: a unique constraint on (user_id, promo_id) so the second insert fails, an atomic conditional update (`UPDATE ... WHERE not_yet_claimed` and check rows-affected), or a transaction with the right isolation/locking. Correctness under concurrency is enforced at the one place that serializes writes, not in the application logic that races.
About thirty seconds