It was built on O_EXCL plus unlink. Under load it failed open, so the fallback path ran with the budget unenforced.
The replacement
The lock is now statefile.file_lock, a kernel byte-range lock, with a retry on PermissionError. The commit that made the change carries tests.
Counting the fallbacks
The change had a second part. The UNENFORCED fallbacks are now counted in the ledger and shown by the CLI background, so a lock that fails open shows up as a number instead of passing silently.
AI Skills
Use this lesson with the AI assistant you already use
The spawn_budget lock, built on O_EXCL plus unlink, failed open under load, so the fallback path ran with the budget unenforced. The fix replaced the lock and also added a count of how often the unenforced fallback happens.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: Make A Lock That Fails Open Visible By Counting Its Fallbacks, Not Just By Fixing The Lock
SOURCE: dxdev.com/blog/exclusive-create-lock-failed-under-load
WHAT HAPPENED: The spawn_budget lock used O_EXCL and unlink, and under load it failed open. When that happened, the fallback path ran and the budget was not enforced. The lock was replaced with statefile.file_lock, a kernel byte-range lock, with a retry on PermissionError, and the commit carries tests. The change had a second part. The UNENFORCED fallbacks are now counted in the ledger and shown by the CLI background command. A lock that fails open now shows up as a number instead of passing silently.
THE RULE: When a guard has a fallback path that runs without enforcement, count every use of that fallback and surface the count where operators look. Fixing the guard is not enough, because the next failure should be visible as a number instead of silent.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Every code path that proceeds without enforcing a limit or lock increments a persistent counter, such as a ledger entry, instead of only logging or doing nothing.
2. The count of unenforced fallbacks is shown in a command or dashboard that people already use, so a nonzero value can be seen without reading source or logs.
3. Locks that guard shared state use a kernel-level mechanism with explicit retry handling for transient errors, and a test exercises the contended case.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
