# A conversation removed or archived during a lock wait is recreated by the waiting writer

- **Status**: Todo
- **Kind**: Bug
- **Authors**: jp
- **Date**: 2026-08-31
- **Label**: domain=conversation
- **Label**: domain=storage
- **Label**: package=jp_workspace
- **Label**: type=bug

## What happens

A command that has already cached a conversation's metadata and events, then
waits for the flock, resurrects that conversation if the lock holder removed or
archived it while it waited.

Reproduction (two terminals, same conversation):

1. `jp c compact ID` — resolves conversation config, which eager-loads metadata
   and events into `Workspace::state`, then blocks on the flock.
2. `jp c rm ID` — holds the flock across `remove_conversation_with_lock`
   (`jp_cli/src/cmd/conversation/rm.rs:102-109`), deletes the conversation from
   both storage roots, releases.
3. Terminal 1 acquires the flock.
   `Workspace::sync_conversation` re-reads both loads, both report
   `LoadErrorInner::is_missing()`, and the `is_missing` arms keep the cached
   copy.
   Compact proceeds and its `flush()` writes the whole conversation back.

The deleted conversation reappears on disk with its pre-wait content.
Nothing tells the user.

## Archive variant

Archiving produces a mixed state rather than a clean resurrection, because the
two loads disagree about the archive partition:

- `FsStorageBackend::load_conversation_metadata` falls back to the archive
  (`jp_storage/src/backend/fs.rs:240`), so metadata refreshes successfully and
  brings `archived_at` with it.
- `load_conversation_stream` has no such fallback
  (`jp_storage/src/backend/fs.rs:250-255`), so the cached stream is kept.

The waiting writer then persists into the *live* partition, producing a live
conversation carrying `archived_at`.

## Not a regression

This predates the lock-refresh work in #1045.
Before that change, `maybe_init_conversation` returned early on an
already-populated cell, so the cached copy survived the deletion and the flush
recreated it — the same outcome, reached by omission instead of by an explicit
arm.

## Why it was not fixed alongside the refresh

Preserving cached data on a missing load is correct for exactly one case: a
conversation created in memory and never persisted (`--no-persist`, the
in-memory backend, `create_conversation` in tests).
Distinguishing that from "another process deleted it" needs provenance we do not
record:

- `state.presence` has an entry for both —
  `create_conversation_with_projection` inserts one.
- `state.conversations` membership likewise covers both.

So the fix needs new state tracking whether a cached value came from the loader
or from an in-process create, with a lifecycle spanning create → first
successful persist.
That touches the highest-risk path in `jp_workspace` and deserves its own
change.

## Sketch

Record ids seeded by `create_conversation_with_projection` in a
`never_persisted: HashSet<ConversationId>`, and clear an id on its first
successful `PersistBackend::write`.
`sync_conversation` then keeps the cached copy on a missing load only for ids in
that set, and returns the missing error otherwise.
Note `sync_conversation` takes `&self`, so the set needs interior mutability or
the persist path needs to own it.

Regression tests: a removal and an archive completed by a second workspace
between the cached read and `lock_conversation`, asserting the acquisition fails
and the conversation stays gone.