fix: move-codex-session should not hang releasing its locks #145
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/move-codex-session-lock-release-hang"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
move-codex-sessioncould hang or exit without output while releasing its writer locks, for three reasons:exitevent that had already fired for a signal-killed helper, so it hung or exited 0 with no output.The script now tracks
closefrom spawn and starts every release before awaiting any (Promise.allSettled), so one stuck helper cannot hold the other home's locks. Release failures are appended to a failed move's error.When the move completed but a release failed, the script exits 1, prints the normal JSON with a new always-present
writerLocksReleased: false, and names the home and reason on stderr. On success the field istrue.SKILL.mdandusage()document it. Failed moves print nothing on stdout, and every failed-move test now asserts that.Rejected shapes:
The 7 lock tests passed in 12 sequential runs. Reverting to the serial release hangs and then fails the new blocked-release test. Success-looking JSON on a failed move fails the stdout assertions. The old late-
exitlistener reproduces both the hang and the silent exit 0. In a Linux container,exitfired before stderr was read in 28 of 2000 concurrent runs, henceclose.Left for a follow-up PR: a helper that prints something other than
readyis never stopped, opposite-direction moves can deadlock, the release-time reacquire has no timeout, and a helper killed mid-move is noticed only at release.🤖 Generated with Claude Code
move-codex-sessionshould not hang releasing its locks 8a0206fd89move-codex-sessionlock-release fixReview
01M4JAKS2E159R10QQBDREFFSF— headcf6fb309c3399376822b1b54b3d9cf1e082caedcReview — j4k-oss/agent-skills @
e33d8035a4Scope: diff against base tree
8a58ec874c49Status: dispatched — coverage complete (5/5 slots terminal)
Facts: current review-wide projection
Computed under:
Findings (0)
No findings survived.
Reviewed:
Other claims
01M4JAXHAJGHXE871Q619VQ8HPhigh — LOCK_HOLDER comment puts lock paths first and omits the leading count01M4JAY9H1XWZ3M1ZPRZ51WX7Pmedium — Lock-release failure report lists leftover.lockfiles without saying the locks are no longer heldCoverage
Coverage pass: 01M4JAM287DRGEBXMH2DNNHN3D
Accounting: complete
Slot health: healthy
move-codex-sessionshould wait out transient locks on its read-only connections #148