fix(index): retry the BM25 writer lock when a spawned process briefly holds it
CI on #308 (docs only) failed in full_text_only_updates_ignore_providers_and_preserve_mode: the second incremental update could not create a BM25 writer (LockBusy).
Cause: tantivy takes its writer lock with a non-blocking flock on .tantivy-writer.lock. When another thread spawns a child process (vera-core tests run git constantly; the MCP server and vera watch also run updates in a process that spawns git), the child inherits the open lock file until it execs. The previous writer drops its handle, but the lock is still held through the child's copy, so the next writer fails at once.
Reproduced before the fix: 5 of 300 sequential insert_batch calls failed while a thread spawned true in a loop. With the fix: 0 failures across repeated runs.
Fix: one Bm25Index::writer helper replaces the five duplicated writer constructions and retries LockBusy for up to 1 s (50 × 20 ms). Vera's own index lock already serializes writers across processes, so the retry cannot mask real contention. The stress case is kept as a regression test.
Summary by CodeRabbit
- Bug Fixes
- Index updates and deletions now retry when the index is temporarily busy, improving reliability during concurrent operations. If the lock remains unavailable after the retries, the operation returns its result as usual.