Jean-Pierre

Appearance

View Markdown
ReferencesT-0vmm72z

Expired-conversation cleanup deletes a conversation whose turn is still running ​

  • Status: Done
  • Kind: Bug
  • Authors: jp
  • Date: 2026-10-01
  • Label: domain=plugins
  • Label: domain=storage
  • Label: package=jp_storage
  • Label: package=jp_workspace

Workspace::remove_ephemeral_conversations (crates/jp_workspace/src/lib.rs:498) removes every conversation whose expires_at has passed, except the ids it is told to skip. Its only caller (crates/jp_cli/src/lib.rs:794-795) skips the conversations some session has active, from all_active_conversation_ids. Nothing checks whether the conversation is locked: PersistBackend::remove goes to Storage::remove_conversation (crates/jp_storage/src/lib.rs:420), which deletes the directories outright.

jp query --tmp is not exposed, because its conversation is activated in the session before the turn runs. A conversation created by a plugin's query with new and expires_in (T-0vmm72z) is never session-active. While its turn runs, any other jp process that reaches teardown deletes it once it has expired. With expires_in: "0s" that is immediately; with 5m, any turn that outlives five minutes. The turn then writes into a removed directory, or recreates a partial one, and the plugin's read_events fails.

Fix ​

Skip conversations whose lock is held, the way sanitize already does through Storage::is_conversation_locked (crates/jp_storage/src/backend/fs.rs:294-296). The check belongs below the CLI, so every caller of the cleanup gets it: in remove_ephemeral_conversations, or in load_expired_conversation_ids itself.

Test ​

Lock an expired conversation through the workspace, run remove_ephemeral_conversations with an empty skip list, and assert the conversation is still on disk. The existing test_remove_ephemeral_conversations (crates/jp_workspace/src/lib_tests.rs:704) has the fixture.

Comments ​

  • From: jp
  • Date: 2026-10-01T10:45:24Z

Fixed in remove_ephemeral_conversations: each expired conversation's lock is taken through the workspace's LockBackend for the removal itself, and a conversation whose lock is held is kept. Taking the lock rather than checking is_conversation_locked closes the window between the check and the delete, and covers every backend rather than only the filesystem one.

Exposed by T-0vmm72z on the same branch: expires_in on a plugin query creates an expiring conversation that no session has active. Before it, only jp conversation edit --tmp on a conversation a plugin turn was running on could reach this.

Test: an_expired_conversation_is_kept_while_its_lock_is_held keeps a locked expired conversation, then removes it once released, so the lock is shown to be what kept it.