mirror of
https://github.com/qdrant/qdrant.git
synced 2026-07-31 15:11:35 -05:00
dcc38ee239
* [AI] fix: bound random-sample pre-allocation by available point count `LocalShard::scroll_randomly` pre-allocated its result set with `HashSet::with_capacity(limit)`, where `limit` is the client-supplied request limit and is unbounded by default (`StrictModeConfig::max_query_limit` is `None` unless an operator sets it). A very large limit made the up-front allocation fail and abort the process (`handle_alloc_error`), which cannot be caught and returned as an error. The sample loop inserts at most `min(limit, total points available across segments)` points, so bound the pre-allocation to what is actually available. Capacity is unchanged for normal requests; only the pathological case is bounded. Same class as the search top-k fix (#4321 / #4328) and the in-flight edge fix (#9374). Adds a regression test. * [AI] fix: cap random-sample preallocation by filtered candidate count Review feedback. `available_point_count_without_deferred()` is filter-unaware, so `availability.iter().sum()` could still drive `HashSet::with_capacity()` to reserve a buffer proportional to the full collection on a highly selective filtered request, re-opening the allocator-abort path on large collections. The sampling loop only ever inserts points read into `segments_reads`, which is filter-aware and already capped at `limit` per segment, so bound the preallocation by that candidate count instead. * Update lib/collection/src/shards/local_shard/scroll.rs Co-authored-by: qdrant-cloud-bot <111755117+qdrant-cloud-bot@users.noreply.github.com> --------- Co-authored-by: Andrey Vasnetsov <vasnetsov93@gmail.com> Co-authored-by: qdrant-cloud-bot <111755117+qdrant-cloud-bot@users.noreply.github.com>