Every other failure path in AtomicWriteFile (Write / Sync / Close /
Chmod) calls os.Remove(tmpPath) before returning the error, so the
`.tmp-*` file CreateTemp produced does not survive an aborted write.
The rename branch — the most common failure mode in practice —
forgot to do the same:
return os.Rename(tmpPath, path)
If os.Rename returns a non-nil error (target is an existing directory,
target file is locked on Windows, cross-filesystem rename, etc.) the
caller gets the error but the orphaned `.tmp-*` is left behind. Repeated
failures litter the parent directory with stale temp files; that's
particularly nasty for the cron and session stores that scan their
own directory looking for state files.
Reproducer (works on every supported platform): pass a path that is
already an existing directory. After the failed call, the parent
contains both `blocked/` and `.tmp-XXXXXXXXXX`.
Fix: handle the rename error the same way the other branches do —
os.Remove(tmpPath) before returning. Add inline comment listing the
realistic failure causes so the next reader doesn't think this is
defensive paranoia.
Add TestAtomicWriteFile_NoTempLeftWhenRenameFails to pin it: writes
to an existing-directory path, asserts the call errors out, asserts
the parent directory contains no stray `.tmp-*` afterward. Confirmed
to fail on main (orphan `.tmp-*` present) and pass on this branch.
Add context-aware select statements when sending events to prevent blocking on closed channels. Implement secure argument logging using RedactArgs to mask sensitive flags. Add atomic file writes and locks for config safety. Improve session handling with mutex protection and deduplication checks.
generated by llmgit
Co-Authored-By: Claude <noreply@anthropic.com>
