Release After Call That Can Fail

What goes wrong

A release, delete or cleanup is written after a call that can throw, or after a newly added early return, or is documented only on the success path, so when that call fails the lock or marker is never released and every later run hits the same held lock and fails the same way.

Example

The job sends an email and then releases its lock; the email call throws, the lock stays held, and every retry of the job finds it locked.

Not to be confused with

The scope is entered and the release merely comes after the failing call; not setup failing before the scope (Setup Cleanup Gap), not a failing test skipping teardown (Failure Path Fixture Leak), not a deadline abandoning work (Abandoning Deadline), and not a flag left set after its operation by design (Marker Outlives Its Operation).

Discovered by

@sks24git GitHub

Field notes · 5

@sks24git2026-11-04beat 1 review round

A watchdog that kills leftover test processes when the runner dies loads the whole test module first. If that load fails after the runner is gone, it exits silently and the orphans loop forever.

Keep a last-resort cleaner dependency-free. It runs when everything else has already failed.
Treat a zombie parent as dead. A signal check still succeeds on it.

@sks24git2026-11-02beat 2 review rounds

A cleanup script ran a strict reset first and the file removal second. When the reset failed, the script stopped early and a stale answer file stayed for the next step to read as real input.

Put the must-run cleanup first in a fail-fast script. Anything after the first error never runs.

@sks24git2026-09-30

A pooled socket's turn lock is taken, then the code awaits a cache write before handing the turn to the guard that frees it on cancel. A cancel in that gap keeps the lock, and every later turn of that chat hangs.

Never suspend between taking a lock and handing its release to a guard. A cancel skips the guard.
Write hints before the irreversible step. A lost hint costs one miss, a lost release a wedge.

@sks24git2026-09-15

The only instruction that ever cleans up after a successful run was printed to stderr, while the last line of stdout said success. Callers read the last stdout line, so the cleanup was never done.

Deliver on the channel your reader actually reads. A remedy on the invisible stream is no remedy.
Learn the caller's reading discipline before you pick a stream.

@sks24git2026-09-10

Cleanup was ordered after a tool call that can fail: read, report, then delete. The call failed, the delete was never reached, each wake failed the same way, and a timer nothing could satisfy woke the thread forever.

Delete before you read. Put the irreversible cleanup before any step that can fail, or the failure keeps the thing alive.