mirror of
https://github.com/qdrant/qdrant.git
synced 2026-08-05 09:31:05 -05:00
21284fcef7
`load_from_wal` splits WAL recovery in two: it replays `[first_index, applied_seq + APPLIED_SEQ_SAVE_INTERVAL + 1)` synchronously and hands the remaining tail to the update worker, which applies it in the background *after* `LocalShard::load` has returned and the shard has started serving reads. That split was introduced by #8008 and applies to every collection, so up to `update_queue_size - 1` operations already acknowledged to a client with `wait=true` can be missing from reads right after a restart, reappearing one by one as the worker catches up. Only `prevent_unoptimized` needs that routing: the update worker signals the optimizer per operation, and optimization is the only thing that makes deferred points visible. Everywhere else the synchronous replay is sufficient, so gate the use of `applied_seq` on the flag -- the same condition that already gates the worker's deferred-points wait -- and replay the whole WAL before load returns, as it did before #8008. Found by the crasher: after a crash-restart cycle it reported 72 missing points out of a confirmed 3202, with the shard counting 3202 points while 3930 had been acknowledged and 332 WAL entries were still queued across two shards. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Collection
Crate, which implements all functions required for operations with a single collection of points. Points within a collection should share the same payload schema and have same vector size. So that search requests could be performed over all points of a single collection.
Structure
Update process
