## Summary When `discrawl tail` is running continuously, `discrawl messages --sync` can block waiting for the same sync lock held by the tail process. This is surprising because plain `discrawl messages` works against the local archive, and the docs/help present `--sync` as a convenient freshness flag for `messages`. This seems related to, but narrower than, #59. That issue fixed read-only commands so `search`, `messages`, and `sql` no longer wait behind `tail`. The remaining case is that `messages --sync` intentionally routes through the sync/writer path, so it can still wait on the long-running tail lock. ## Reproduction 1. Configure Discrawl with a local SQLite archive and Discord access. 2. Start a long-running tail process, for example: ```sh discrawl tail --repair-every 6h ``` 3. In another shell, run a messages query with sync enabled: ```sh discrawl messages --channel <channel-id-or-name> --last 20 --include-empty --sync ``` ## Actual behavior The command waits for `.discrawl-sync.lock` while it is held by the live `tail` process, and eventually exits with a lock wait/context cancellation error if the caller has a timeout. ## Expected behavior One of these would be easier for operators and agent callers: - Detect that a live `tail` process already owns the sync role and skip/fall back to the local read path. - Fail fast with a clear message such as “tail already owns live sync; omit --sync while tail is running.” - Narrow the long-running tail lock so it is not held for the whole tail lifetime, if that is safe. - At minimum, document in `messages --help` / README that `--sync` is not appropriate while `tail` is already maintaining the archive. ## Why this matters The local archive may already be queryable and fresh enough via `tail`, but callers that follow the documented `messages --sync` pattern see a command failure instead of a useful read. This is especially easy to hit in automation, where `--sync` looks like a harmless freshness guard. ## Environment Observed on Discrawl 0.10.0. The issue is independent of any specific channel, guild, path, or service manager: it is the interaction between a long-running `tail` process and a concurrent `messages --sync` invocation.