# `unarchive` moves a conversation between partitions without a lock

- **Status**: Todo
- **Kind**: Bug
- **Authors**: jp
- **Date**: 2026-08-15

`Workspace::unarchive_conversation` moves a conversation directory out of the
archive partition into the live one without holding its conversation lock.
All three call sites go in bare: `unarchive.rs:41`, `use_.rs:163`,
`use_.rs:248`.

Anything that reads the two partitions concurrently can therefore observe the
conversation in neither.
`Workspace::cleanup_stale_files` is the case that prompted this: it treats
"absent from both partitions" as grounds for pruning a session's history entry,
and falls back to `lock_info` to spot a conversation that is mid-write.
That fallback finds nothing during an unarchive, because no lock is taken.

## Scope

Cleanup's own exposure is already narrowed in `f6a3c957`: it re-reads the live
partition after the archive scan, so a single move in either direction is caught
by one of the scans.
That does not cover multiple concurrent transitions, and it does nothing for any
other reader of the two partitions.

The underlying issue is that unarchive is the one partition-moving operation
that does not participate in the conversation-locking protocol.
`archive` takes a `ConversationMut` and therefore holds the lock; `unarchive`
takes a bare `&ConversationId`.

## Notes

Fixing this means changing the signature of `unarchive_conversation` to require
proof of the lock, in the shape `archive_conversation` already uses, and
updating the three call sites to acquire it.
Worth checking whether the picker paths in `use_.rs` can acquire a lock at the
point they currently call through, or whether they need restructuring first.