Unlinking a conversation lock file on release can leave two holders

• Status: Todo
• Kind: Bug
• Authors: jp
• Date: 2026-09-10
• Label: domain=storage
• Label: package=jp_storage
• Label: package=jp_workspace
• Label: type=bug

Conversation lock files are unlinked while other processes may be acquiring them, so two processes can hold write exclusion on the same conversation at the same time. The exclusion is advisory on an inode, and the pathname is what every acquisition resolves; unlinking separates the two.

The interleaving

FsResourceGuard::drop (crates/jp_storage/src/resource_lock.rs) closes the file handle, releasing the flock, and then unlinks the path:

1. A closes its handle. The OS lock on inode I is released; the path still resolves to I.
2. B opens the path, gets I, and takes the lock. B is a legitimate holder.
3. A unlinks the path. B now holds a lock on an unlinked inode, and the presence marker for the conversation is gone.
4. C opens the path, creating inode J, and takes the lock.

B and C both report success and can write the same conversation with no exclusion between them. is_conversation_locked also reports the conversation unlocked while B holds it, because lock_file_path decides on exists().

The window in step 2 is the few instructions between the close and the unlink, so try_lock narrows it but does not close it. A blocking acquisition turns it into a certainty, which is why FsResourceLocker::lock refuses to run with remove_on_drop set.

Two unlink sites, not one

• Guard drop, above. try_lock_conversation opts into it with with_remove_on_drop, because the lock file doubles as the presence marker that is_conversation_locked and the orphan scan read.
• Workspace::cleanup_stale_files (crates/jp_workspace/src/session_mapping.rs) unlinks every path returned by Storage::list_orphaned_lock_files, and runs at the end of every invocation. The orphan test is itself an open-then-flock, so it can unlink a file another process locked between the two.

Plausible input

Two jp invocations against the same conversation, one releasing as the other acquires — jp query finishing while a second jp query or jp c rm waits on the same id. Contention is ordinary; landing inside the close/unlink window is rare. The damage neither stays put nor shows itself: two unserialized writers against a conversation's durable state, reported as success by both.

Direction

Make conversation lock files stable inodes, never unlinked while acquisition can run, and find another representation for the presence marker that is_conversation_locked and the orphan scan depend on. That means:

• Drop with_remove_on_drop from try_lock_conversation, and with it the option on FsResourceLocker if nothing else wants it.
• Decide what "no lock file exists" means once files persist — Storage::lock_file_path currently signals the write location through Err(path) on the strength of exists().
• Stop cleanup_stale_files from unlinking lock files, or bound when it may.

RFD 106 designs the ID allocator lock around exactly this property ("The lock file is never unlinked, so it is a stable inode and the release-then-unlink hazard does not apply to it") and scopes the conversation-lock case out ("that is a pre-existing bug, out of scope here"). This ticket is that case.

Testing

A regression test has to control the interleaving rather than run the steps in sequence — the existing test_fs_remove_on_drop acquires and drops in order and never overlaps. Something that holds the guard's drop between the close and the unlink while a second acquisition runs, or three coordinated processes.