Current Behavior

The Qdrant server panics and crashes when processing a specific search request via gRPC. The error log indicates an assertion failure in fixed_length_priority_queue.rs, explicitly stating that the length must be greater than zero.

This issue persists even after:

1. Upgrading to version v1.16.3.
2. Completely wiping the storage and rebuilding the collection from scratch.

Panic Log:

2026-01-22T05:50:28.033493Z ERROR qdrant::startup: Panic occurred in file /qdrant/lib/common/common/src/fixed_length_priority_queue.rs at line 40: length must be greater than zero
2026-01-22T05:50:28.034748Z ERROR qdrant::startup: Panic backtrace: 
   0: qdrant::startup::setup_panic_hook::{{closure}}
   ...
   7: shard::search_result_aggregator::SearchResultAggregator::new
   8: collection::shards::local_shard::search::<impl collection::shards::local_shard::LocalShard>::do_search_impl::{{closure}}
   ...
   17: <qdrant::tonic::api::points_internal_api::PointsInternalService ... >::core_search_batch

Steps to Reproduce

Deploy Qdrant in a distributed environment (Kubernetes) or with ShardNumber > 1 (e.g., 10 shards).

Use the gRPC client (e.g., qdrant-go-client).

Expected Behavior

The request should not panic.

Context (Environment)

Qdrant Version: v1.16.3

Deployment: Kubernetes (K8s), Docker

Configuration: Distributed / Sharded collection (ShardNumber: 10)

Client: qdrant-go-client

Workload: High frequency of vector updates and deletions. A batch process executes upsert and delete operations approximately every 5 minutes. The collection size is approximately 500,000 vectors. This frequent churn might be relevant to segment optimization or indexing state during the search.