qdrant_client/proto/collections.proto (1)

368-370: ⚡ Quick win

Resolve TODO field lifecycle in public schema before merge.

Line 368 introduces plus with a TODO in a public proto message. If this field is temporary, remove it now and reserve tag 3 to avoid future wire-compatibility ambiguity.

Suggested schema adjustment

 message TurboQuantization{
   optional bool always_ram = 1;
   optional TurboQuantBitSize bits = 2;
-
-  // TODO(turbo): Remove before release
-  optional bool plus = 3;
+  // Reserved to prevent accidental tag reuse from pre-release experiments.
+  reserved 3;
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@qdrant_client/proto/collections.proto` around lines 368 - 370, Remove the
temporary optional field "plus" (optional bool plus = 3;) from the public proto
message and replace it by reserving tag 3 (reserve 3;) to preserve wire
compatibility; remove the TODO comment and ensure any references to the "plus"
field in code/clients are deleted or migrated to avoid compilation/runtime
errors.

qdrant_client/http/models/models.py (1)

2952-2960: ⚡ Quick win

Constrain mode to known values instead of plain str.

At Line 2957, mode is documented as high_cpu/high_io but typed as str. Using Literal["high_cpu", "high_io"] (or a small enum) improves validation and generated client typing.

Proposed change

+from typing import Literal
...
 class SearchThreadPoolTelemetry(BaseModel):
@@
-    mode: str = Field(..., description="Currently active mode (`high_cpu` or `high_io`).")
+    mode: Literal["high_cpu", "high_io"] = Field(
+        ..., description="Currently active mode (`high_cpu` or `high_io`)."
+    )

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@qdrant_client/http/models/models.py` around lines 2952 - 2960, Change the
SearchThreadPoolTelemetry.mode field from a plain str to a constrained type so
only "high_cpu" or "high_io" are accepted: update the type annotation for mode
in the SearchThreadPoolTelemetry model to either typing.Literal["high_cpu",
"high_io"] or a small enum (e.g., class SearchMode(Enum): HIGH_CPU="high_cpu";
HIGH_IO="high_io") and adjust the Field import/usage accordingly so Pydantic
validation and generated client typing reflect the two allowed values.

tests/conversions/fixtures.py (1)

260-281: ⚡ Quick win

Add a TurboQuant fixture variant with model_id to close a round-trip coverage gap.

Current turbo fixtures validate bits variants, but they don’t exercise model_id preservation. Adding one fixture with model_id would catch mapping regressions immediately.

Proposed fixture extension

+turbo_quantization_with_model = grpc.TurboQuantization(
+    model_id="test-model-v1",
+    bits=grpc.TurboQuantBitSize.Bits2,
+)
+
+turbo_quantization_config_with_model = grpc.QuantizationConfig(
+    turboquant=turbo_quantization_with_model,
+)
+
+quantization_config_diff_turbo_with_model = grpc.QuantizationConfigDiff(
+    turboquant=turbo_quantization_with_model,
+)

     "QuantizationConfig": [
         quantization_config,
         binary_quantization_config,
         binary_quantization_config_0,
         binary_quantization_config_1,
         binary_quantization_config_2,
         binary_quantization_config_3,
         turbo_quantization_config,
         turbo_quantization_config_minimal,
         turbo_quantization_config_bits1,
         turbo_quantization_config_bits1_5,
         turbo_quantization_config_bits4,
+        turbo_quantization_config_with_model,
     ]
     + product_quantizations,
     "QuantizationConfigDiff": [
         quantization_config_diff_disabled,
         quantization_config_diff_scalar,
         quantization_config_diff_product,
         quantization_config_diff_turbo,
         quantization_config_diff_binary,
+        quantization_config_diff_turbo_with_model,
     ],

Also applies to: 855-874, 1777-1783

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/conversions/fixtures.py` around lines 260 - 281, Add a
TurboQuantization fixture that includes a model_id field to exercise round-trip
preservation of model identifiers: create a new variable (e.g.,
turbo_quantization_with_model_id) alongside the existing fixtures
(turbo_quantization, turbo_quantization_minimal, turbo_quantization_bits1,
turbo_quantization_bits1_5, turbo_quantization_bits4) and instantiate
grpc.TurboQuantization with a representative model_id string plus whatever other
fields you want (e.g., bits or always_ram) so serializers/mappers preserve
model_id during conversion tests.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

qdrant_client/local/local_collection.py (1)

2860-2864: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Preserve datatype when creating dense named vectors.

The new dense-vector path still drops DenseVectorConfig.datatype, so local collections silently create the vector with the default dtype even when the caller requested another one.

Suggested fix

         params = models.VectorParams(
             size=config.size,
             distance=config.distance,
             multivector_config=config.multivector_config,
+            datatype=config.datatype,
         )

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@qdrant_client/local/local_collection.py` around lines 2860 - 2864, The
dense-vector creation path drops the DenseVectorConfig.datatype so vectors use
the default dtype; update the VectorParams construction to preserve the
requested dtype by setting the datatype field from the DenseVectorConfig (e.g.
change the models.VectorParams call that builds params to include
datatype=config.datatype). Locate the vector creation code using
models.VectorParams and the DenseVectorConfig instance named config and pass
config.datatype through so the local collection creates the named dense vector
with the correct dtype.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

qdrant_client/async_qdrant_remote.py (2)

2220-2243: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Fail fast on unsupported vector_name_config types in gRPC path.

At Line [2220], only REST-model configs are matched. Any other runtime value leaves both dense_config and sparse_config unset, and Line [2249] still sends the request with an empty config instead of raising a client-side error.

💡 Suggested fix

             if isinstance(vector_name_config, models.DenseVectorNameConfig):
                 cfg = vector_name_config.dense
                 dense_config = grpc.DenseVectorCreationConfig(
                     size=cfg.size,
                     distance=RestToGrpc.convert_distance(cfg.distance),
                     multivector_config=RestToGrpc.convert_multivector_config(
                         cfg.multivector_config
                     )
                     if cfg.multivector_config is not None
                     else None,
                     datatype=RestToGrpc.convert_datatype(cfg.datatype)
                     if cfg.datatype is not None
                     else None,
                 )
             elif isinstance(vector_name_config, models.SparseVectorNameConfig):
                 cfg = vector_name_config.sparse
                 sparse_config = grpc.SparseVectorCreationConfig(
                     modifier=RestToGrpc.convert_modifier(cfg.modifier)
                     if cfg.modifier is not None
                     else None,
                     datatype=RestToGrpc.convert_datatype(cfg.datatype)
                     if cfg.datatype is not None
                     else None,
                 )
+            else:
+                raise TypeError(
+                    f"Unsupported vector_name_config type: {type(vector_name_config)}; "
+                    f"value={vector_name_config!r}"
+                )

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@qdrant_client/async_qdrant_remote.py` around lines 2220 - 2243, The code path
that builds grpc.DenseVectorCreationConfig / grpc.SparseVectorCreationConfig
only handles models.DenseVectorNameConfig and models.SparseVectorNameConfig,
leaving dense_config and sparse_config unset for any other runtime type; update
the logic around the vector_name_config handling (the block that uses
RestToGrpc.convert_* and constructs
DenseVectorCreationConfig/SparseVectorCreationConfig) to detect unsupported
types and immediately raise a clear client-side error (e.g., ValueError or
TypeError) referencing vector_name_config, instead of falling through and
sending an empty config; ensure the exception is thrown before the request is
built/sent so callers get fast, explicit failure when an unexpected
vector_name_config type is provided.

---

2244-2248: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Do not drop grpc-native ordering values.

At Line [2244] and Line [2284], non-models.WriteOrdering inputs are coerced to None. That silently discards valid grpc ordering values in gRPC mode.

💡 Suggested fix

-            grpc_ordering = (
-                RestToGrpc.convert_write_ordering(ordering)
-                if isinstance(ordering, models.WriteOrdering)
-                else None
-            )
+            grpc_ordering = ordering
+            if isinstance(ordering, models.WriteOrdering):
+                grpc_ordering = RestToGrpc.convert_write_ordering(ordering)
...
-            grpc_ordering = (
-                RestToGrpc.convert_write_ordering(ordering)
-                if isinstance(ordering, models.WriteOrdering)
-                else None
-            )
+            grpc_ordering = ordering
+            if isinstance(ordering, models.WriteOrdering):
+                grpc_ordering = RestToGrpc.convert_write_ordering(ordering)

Also applies to: 2284-2288

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@qdrant_client/async_qdrant_remote.py` around lines 2244 - 2248, The code
currently coerces non-models.WriteOrdering inputs to None, which drops valid
gRPC-native ordering values; update both places where grpc_ordering (and the
similar variable at the second occurrence) is set — using
RestToGrpc.convert_write_ordering(ordering) if isinstance(ordering,
models.WriteOrdering) else keep the original ordering value (i.e., pass through
the incoming grpc-native ordering) instead of None — so replace the else branch
to return the original ordering; reference the grpc_ordering assignment and
RestToGrpc.convert_write_ordering usages in async_qdrant_remote.py (also apply
the same change at the second occurrence around the later lines).

qdrant_client/qdrant_remote.py (2)

2427-2456: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Reject unsupported vector_name_config inputs before sending gRPC request.

At Line [2427], only two model variants are parsed. For any other runtime type, both configs stay unset and Line [2462] still sends CreateVectorNameRequest, leading to a server-side failure instead of a clear client error.

💡 Suggested fix

             if isinstance(vector_name_config, models.DenseVectorNameConfig):
                 cfg = vector_name_config.dense
                 dense_config = grpc.DenseVectorCreationConfig(
                     size=cfg.size,
                     distance=RestToGrpc.convert_distance(cfg.distance),
                     multivector_config=(
                         RestToGrpc.convert_multivector_config(cfg.multivector_config)
                         if cfg.multivector_config is not None
                         else None
                     ),
                     datatype=(
                         RestToGrpc.convert_datatype(cfg.datatype)
                         if cfg.datatype is not None
                         else None
                     ),
                 )
             elif isinstance(vector_name_config, models.SparseVectorNameConfig):
                 cfg = vector_name_config.sparse
                 sparse_config = grpc.SparseVectorCreationConfig(
                     modifier=(
                         RestToGrpc.convert_modifier(cfg.modifier)
                         if cfg.modifier is not None
                         else None
                     ),
                     datatype=(
                         RestToGrpc.convert_datatype(cfg.datatype)
                         if cfg.datatype is not None
                         else None
                     ),
                 )
+            else:
+                raise TypeError(
+                    f"Unsupported vector_name_config type: {type(vector_name_config)}; "
+                    f"value={vector_name_config!r}"
+                )

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@qdrant_client/qdrant_remote.py` around lines 2427 - 2456, The code only
handles models.DenseVectorNameConfig and models.SparseVectorNameConfig but
proceeds to call CreateVectorNameRequest even when neither branch ran; add an
explicit else that rejects unsupported vector_name_config types (e.g., raise
TypeError or ValueError with a clear message) before building/sending the gRPC
CreateVectorNameRequest so the client fails fast; update the logic around
vector_name_config, dense_config, and sparse_config (same block that checks
isinstance against models.DenseVectorNameConfig and
models.SparseVectorNameConfig) to validate input and surface a helpful error
instead of letting the server return an opaque failure.

---

2457-2461: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Preserve grpc ordering values in gRPC mode.

At Line [2457] and Line [2496], ordering is dropped to None unless it is models.WriteOrdering. This can silently remove requested ordering semantics.

💡 Suggested fix

-            grpc_ordering = (
-                RestToGrpc.convert_write_ordering(ordering)
-                if isinstance(ordering, models.WriteOrdering)
-                else None
-            )
+            grpc_ordering = ordering
+            if isinstance(ordering, models.WriteOrdering):
+                grpc_ordering = RestToGrpc.convert_write_ordering(ordering)
...
-            grpc_ordering = (
-                RestToGrpc.convert_write_ordering(ordering)
-                if isinstance(ordering, models.WriteOrdering)
-                else None
-            )
+            grpc_ordering = ordering
+            if isinstance(ordering, models.WriteOrdering):
+                grpc_ordering = RestToGrpc.convert_write_ordering(ordering)

Also applies to: 2496-2500

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@qdrant_client/qdrant_remote.py` around lines 2457 - 2461, The code currently
sets grpc_ordering to None unless ordering is a models.WriteOrdering, which
drops already-formed gRPC ordering enums; update the logic around grpc_ordering
(the assignment using RestToGrpc.convert_write_ordering) so it preserves
ordering when it is already a gRPC enum: if ordering is an instance of
models.WriteOrdering call RestToGrpc.convert_write_ordering(ordering), else if
ordering is not None assign grpc_ordering = ordering (preserve existing gRPC
enum), otherwise None; apply the same change for both places that set
grpc_ordering (the blocks referencing RestToGrpc.convert_write_ordering and
models.WriteOrdering).