Conversation
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
lib/collection/src/shards/dummy_shard.rs(3 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.rs
📄 CodeRabbit inference engine (.github/review-rules.md)
**/*.rs: Prefer explicit SomeType::from(x) over implicit x.into() in Rust code
Do not use transmute_from_u8, transmute_to_u8, transmute_from_u8_to_slice, transmute_from_u8_to_mut_slice, transmute_to_u8_slice in new code; use bytemuck or zerocopy instead
Files:
lib/collection/src/shards/dummy_shard.rs
**/src/**/*.rs
📄 CodeRabbit inference engine (.github/review-rules.md)
**/src/**/*.rs: Prefer exhaustive match arms over a catch-all _ arm to avoid missing new enum variants (except in tests/benchmarks or when provably safe)
Prefer explicit field ignoring with : _ over .. in struct patterns (except in tests/benchmarks or when provably safe)
Files:
lib/collection/src/shards/dummy_shard.rs
🧠 Learnings (1)
📚 Learning: 2025-08-10T18:30:02.986Z
Learnt from: generall
Repo: qdrant/qdrant PR: 7006
File: lib/collection/src/operations/verification/update.rs:158-174
Timestamp: 2025-08-10T18:30:02.986Z
Learning: In Qdrant's strict mode verification code (lib/collection/src/operations/verification/update.rs), exhaustive pattern matching without `..` is intentionally used for structs like PointsBatch and PointsList. This design pattern ensures compilation fails when new fields are added, forcing developers to explicitly consider how new fields should be handled in the indexed_filter_write method. This provides visibility and compile-time safety for struct evolution.
Applied to files:
lib/collection/src/shards/dummy_shard.rs
🔇 Additional comments (2)
lib/collection/src/shards/dummy_shard.rs (2)
15-15: LGTM!The import is necessary for matching on operation types in the
updatemethod.
24-24: LGTM!The
UpdateStatusimport is required for constructing theUpdateResultwithUpdateStatus::Acknowledged.
Co-authored-by: Tim Visée <tim+github@visee.me>
This comment was marked as resolved.
This comment was marked as resolved.
Co-authored-by: Tim Visée <tim+github@visee.me>
Payload ops are applied as consensus operations, which leads to crash loop on dummy shards.
We rebuild payload indices when loading
LocalShard, and to switch fromDummyShardtoLocalShardwe have to load theLocalShardfrom disk, so it should be safe-enough to allow dummy shards to "ignore" payload operations.All Submissions:
devbranch. Did you create your branch fromdev?New Feature Submissions:
cargo +nightly fmt --allcommand prior to submission?cargo clippy --all --all-featurescommand?Changes to Core Features: