src/common/telemetry_ops/distributed_telemetry.rs (3)

1-1: Consider removing #![expect(dead_code)] if the module is publicly exported.

The DistributedTelemetryData struct and resolve_telemetries method are publicly exported and referenced by the schema generator. This attribute may be masking genuine unused code that could be removed, or it may be premature if the public API will be consumed soon.

If this is temporary scaffolding until the calling code is merged, consider adding a comment explaining the expected timeline.

---

272-274: Consider using a HashSet for missing_peers to improve lookup performance.

missing_peers.contains(peer_id) performs a linear O(n) search for each peer. If the cluster has many peers and/or many missing peers, this becomes O(n×m). Converting missing_peers to a HashSet at the start of the function would make lookups O(1).

🔎 Proposed fix

 fn aggregate_peers_info(
     missing_peers: Vec<u64>,
     base_cluster: &ClusterTelemetry,
     telemetry_by_peer: &HashMap<u64, &TelemetryData>,
 ) -> Option<HashMap<u64, DistributedPeerInfo>> {
     let all_peers = base_cluster.peers.as_ref()?;
+    let missing_peers_set: ahash::HashSet<u64> = missing_peers.iter().copied().collect();

     let mut distributed_peers_info = HashMap::default();
     for (peer_id, peer_info) in all_peers {
         let responsive =
-            telemetry_by_peer.contains_key(peer_id) && !missing_peers.contains(peer_id);
+            telemetry_by_peer.contains_key(peer_id) && !missing_peers_set.contains(peer_id);

---

296-325: Defensive code for unexpected missing peers.

The debug_assert!(false, ...) on line 298 indicates this code path is not expected to execute under normal conditions. The subsequent logic gracefully handles the case anyway, which is good defensive programming. Consider adding a log::warn! in release mode to surface unexpected situations in production.

🔎 Optional: Add logging for unexpected path

     // Add any failed peers that aren't in the all_peers list
     for peer_id in missing_peers {
         debug_assert!(false, "all missing peers should have been listed already");
+        log::warn!("Missing peer {peer_id} was not in the all_peers list");

         if distributed_peers_info.contains_key(&peer_id) {
             continue;
         }

docs/redoc/master/openapi.json (1)

16342-16483: Distributed telemetry schemas look good; only minor consistency nits

The new DistributedTelemetryData, DistributedCollectionTelemetry, DistributedClusterTelemetry, and DistributedPeerInfo definitions are structurally consistent with the existing telemetry schemas and reuse the right component types (ReshardingInfo, ShardTransferInfo, StateRole, ConsensusThreadStatus). This is a clean, additive extension and shouldn’t break existing clients.

Two minor, optional consistency points you may want to consider in the Rust schemas (not here, since this JSON is generated):

• DistributedClusterTelemetry.number_of_peers (Line 16406) and DistributedPeerInfo.num_pending_operations (Line 16465) use format: "uint64", whereas similar counters elsewhere (e.g. ClusterStatusTelemetry.number_of_peers, RaftInfo.pending_operations) use format: "uint". If the underlying Rust types are the same, aligning formats would keep the OpenAPI surface more uniform.
• Naming-wise, num_pending_operations vs existing pending_operations is slightly inconsistent; either is fine, but using the same naming pattern everywhere would reduce cognitive load for API users.

Functionally everything here looks correct, so these can be deferred unless you particularly care about OpenAPI cosmetic consistency.

Based on learnings, if you want to adjust descriptions or field types, please do it in the Rust schema sources (e.g. lib/api/src/rest/schema.rs) so this JSON stays generated.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Learnt from: generall
Repo: qdrant/qdrant PR: 7183
File: lib/api/src/grpc/qdrant.rs:4263-4273
Timestamp: 2025-09-16T19:14:17.614Z
Learning: In qdrant, lib/api/src/grpc/qdrant.rs is auto-generated by prost-build; do not edit it directly. Make changes in lib/api/src/grpc/proto/points.proto (e.g., add [deprecated=true], doc comments, or encoding options), then regenerate the Rust code.

Learnt from: generall
Repo: qdrant/qdrant PR: 7006
File: docs/redoc/master/openapi.json:13645-13652
Timestamp: 2025-08-10T18:26:12.443Z
Learning: In qdrant, docs/redoc/master/openapi.json is auto-generated from the REST schemas. To change field docs, edit lib/api/src/rest/schema.rs (e.g., add doc comments or #[schemars(description = ...)]). Specifically, UpdateVectors.update_filter lacked a description and should state: "If specified, only update vectors for points that match this filter; points not matching the filter are left unchanged."

Learnt from: generall
Repo: qdrant/qdrant PR: 7006
File: docs/redoc/master/openapi.json:10393-10401
Timestamp: 2025-08-10T18:26:33.017Z
Learning: In qdrant, docs/redoc/master/openapi.json is auto-generated. Any description changes must be made in the source (e.g., lib/api/src/rest/schema.rs and/or lib/api/src/grpc/proto/points.proto), not edited directly in the JSON.