lib/segment/src/types.rs (2)

1029-1034: LGTM; tweak doc string grammar.

Change “payload index” -> “payload indexes”.

-    /// Max number of payload index in a collection
+    /// Max number of payload indexes in a collection

---

1174-1178: Mirror doc string grammar fix in output type.

Same pluralization nit in StrictModeConfigOutput.

-    /// Max number of payload index in a collection
+    /// Max number of payload indexes in a collection

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

7451-7458: Output schema: wording + minimum alignment with other strict-mode fields

• Grammar: use “payload indexes” (or “indices”) plural.
• Consistency: other output strict-mode limits (e.g., max_points_count) allow minimum: 0 while the config (input) uses minimum: 1. Consider minimum: 0 here as well so users can explicitly disallow payload indexes via output, mirroring existing pattern.

Apply:

           "sparse_config": {
             "description": "Sparse vector configuration",
             "anyOf": [
               {
                 "$ref": "#/components/schemas/StrictModeSparseConfigOutput"
               },
               {
                 "nullable": true
               }
             ]
           },
-          "max_payload_index_count": {
-            "description": "Max number of payload index in a collection",
+          "max_payload_index_count": {
+            "description": "Max number of payload indexes in a collection",
             "type": "integer",
             "format": "uint",
-            "minimum": 1,
+            "minimum": 0,
             "nullable": true
           }

---

10005-10012: Input schema: wording only (keep minimum: 1)

Retain minimum: 1 for the config (input) to match existing strict-mode patterns, but fix the description plural.

-          "max_payload_index_count": {
-            "description": "Max number of payload index in a collection",
+          "max_payload_index_count": {
+            "description": "Max number of payload indexes in a collection",
             "type": "integer",
             "format": "uint",
             "minimum": 1,
             "nullable": true
           }

Please confirm if allowing 0 in the output is intended (to represent “no payload indexes allowed”). If not, we can keep minimum: 1 in both places for symmetry.

lib/api/src/grpc/proto/collections.proto (1)

372-378: Document semantics: scope, inclusivity, and enforcement timing for max_payload_index_count.

Please add a brief comment clarifying:

• Scope: per-collection total across all fields/shards.
• Inclusivity: whether the limit is inclusive (e.g., equals allowed).
• Enforcement: checked only on creation-time; existing indexes aren’t auto-dropped if the limit is later lowered.
• Zero/negative semantics: 0 should be treated as “unlimited” or rejected.

Suggested proto doc:

   optional uint64 max_points_count = 18;
-  optional uint64 max_payload_index_count = 19;
+  // Maximum number of payload indexes allowed in this collection (across all fields/shards).
+  // If unset -> no limit. If set, the limit is inclusive (creation of the N+1-th index is rejected).
+  // Enforcement occurs at payload-index creation time; existing indexes are not removed if the limit decreases.
+  // Recommended: treat 0 as invalid and reject it server-side.
+  optional uint64 max_payload_index_count = 19;

tests/openapi/test_strictmode.py (1)

2467-2470: Optional: assert config reflects the increased limit.

Add a quick GET/assert after bumping to 2 to verify propagation.

     set_strict_mode(collection_name, {
         "enabled": True,
         "max_payload_index_count": 2,
     })
+    resp = request_with_validation(
+        api='/collections/{collection_name}', method="GET",
+        path_params={'collection_name': collection_name},
+    )
+    assert resp.ok
+    assert resp.json()['result']['config']['strict_mode_config']['max_payload_index_count'] == 2

src/common/update.rs (2)

813-820: Avoid lossy cast; saturate Duration→usize seconds conversion.

Future non-None timeouts could truncate on 32-bit/large durations.

Apply this diff:

-    let wait_timeout: Option<Duration> = None; // ToDo: make it configurable
+    let wait_timeout: Option<Duration> = None; // ToDo: make it configurable
+    let timeout_secs = wait_timeout.map(|d| d.as_secs().min(usize::MAX as u64) as usize);
@@
-    let pass = check_strict_mode(
+    let pass = check_strict_mode(
         &operation,
-        wait_timeout.map(|d| d.as_secs() as usize),
+        timeout_secs,
         &collection_name,
         &dispatcher,
         &access,
     )

---

826-831: Fail fast on missing field_schema before strict-mode check.

This returns a precise 400 earlier and skips an unnecessary info fetch/strict check.

Apply this diff:

-    let Some(field_schema) = operation.field_schema else {
-        return Err(StorageError::bad_request(
-            "Can't auto-detect field type, please specify `field_schema` in the request",
-        ));
-    };
+    let field_schema = operation
+        .field_schema
+        .as_ref()
+        .ok_or_else(|| StorageError::bad_request(
+            "Can't auto-detect field type, please specify `field_schema` in the request",
+        ))?
+        .clone();

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: generall
PR: qdrant/qdrant#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.

lib/api/src/grpc/qdrant.rs (1)

713-714: Clarify 0 vs None semantics and add min=1 validation; ensure safe usize conversion elsewhere

• Decide whether Some(0) means “no indices allowed” or if “unlimited” should be None. If 0 is invalid, add a min=1 validator so it matches other strict-mode numeric caps.
• Please add the validator in the source proto/generator (not this generated file) so the generated Rust includes it like below.
• In conversions mapping this field to internal usize, replace as usize with usize::try_from(...) to avoid silent overflow on 32‑bit targets.

Apply via proto/generator so the generated Rust contains (illustrative):

-    #[prost(uint64, optional, tag = "19")]
-    pub max_payload_index_count: ::core::option::Option<u64>,
+    #[prost(uint64, optional, tag = "19")]
+    #[validate(range(min = 1))]
+    pub max_payload_index_count: ::core::option::Option<u64>,

Run to confirm no unsafe casts remain and to see all call sites:

#!/bin/bash
set -euo pipefail

echo "Occurrences of max_payload_index_count:"
rg -n -C2 --hidden --glob '!.git' 'max_payload_index_count'

echo
echo "Potentially unsafe u64 -> usize casts near this field:"
rg -n -C3 --hidden --glob '!.git' -t rs 'max_payload_index_count.*as\s+usize' || true

lib/segment/src/types.rs (1)

1030-1034: Allow 0 (to fully forbid indices) and fix pluralization.

Align with prior feedback: a minimum of 0 is useful to entirely prevent payload index creation. Also fix “index” → “indices”.

Apply this diff in both structs:

-    /// Max number of payload index in a collection
+    /// Max number of payload indices in a collection (0 forbids creating any payload indices)
     #[serde(skip_serializing_if = "Option::is_none")]
-    #[validate(range(min = 1))]
+    #[validate(range(min = 0))]
     pub max_payload_index_count: Option<usize>,

Also applies to: 1174-1178

src/common/update.rs (1)

180-199: Don’t block re‑indexing the same field; count only net‑new indexes.

If the target field is already indexed, allow the request even at the limit. Also improve the error with current/limit.

Apply:

-        if let Some(max_payload_index_count) = strict_mode_config.max_payload_index_count {
-            let collection_info = collection.info(&ShardSelectorInternal::All).await?;
-            if collection_info.payload_schema.len() >= max_payload_index_count {
-                return Err(CollectionError::strict_mode(
-                    format!(
-                        "Collection already has the maximum number of payload indices ({max_payload_index_count})"
-                    ),
-                    "Please delete an existing index before creating a new one.",
-                ));
-            }
-        }
+        if let Some(max_payload_index_count) = strict_mode_config.max_payload_index_count {
+            let collection_info = collection.info(&ShardSelectorInternal::All).await?;
+            let current = collection_info.payload_schema.len();
+            let already_indexed = collection_info
+                .payload_schema
+                .contains_key(&self.field_name);
+            if !already_indexed && current >= max_payload_index_count {
+                return Err(CollectionError::strict_mode(
+                    format!(
+                        "Collection would exceed the maximum payload index count: current={current}, limit={max_payload_index_count}"
+                    ),
+                    "Delete an existing index or raise the limit.",
+                ));
+            }
+        }

docs/grpc/docs.md (1)

1599-1600: Add missing description and fix pluralization for new field.

Use: “Max number of payload indexes in a collection.” Also update the proto comment (StrictModeConfig.max_payload_index_count) so this doc regenerates consistently.

-| max_payload_index_count | [uint64](#uint64) | optional |  |
+| max_payload_index_count | [uint64](#uint64) | optional | Max number of payload indexes in a collection. |

tests/openapi/test_strictmode.py (1)

2464-2464: Fix leading space in asserted error substrings (duplicate of prior review).

Leading space can cause false negatives; remove it.

-    assert " Collection already has the maximum number of payload indices (1). Help: Please delete an existing index before creating a new one." in response.json()['status']['error']
+    assert "Collection already has the maximum number of payload indices (1). Help: Please delete an existing index before creating a new one." in response.json()['status']['error']
@@
-    assert " Collection already has the maximum number of payload indices (2). Help: Please delete an existing index before creating a new one." in response.json()['status']['error']
+    assert "Collection already has the maximum number of payload indices (2). Help: Please delete an existing index before creating a new one." in response.json()['status']['error']

Also applies to: 2502-2502

lib/api/src/grpc/proto/collections.proto (1)

377-378: Clarify semantics, fix wording, and document zero-value; verify safe downstream casts

• Please add a brief comment clarifying behavior: applies only when strict mode is enabled; define what 0 means (reject vs unlimited) and keep this consistent across API, conversions, and tests.
• Align wording with docs: use “payload indexes” (or “indices”) consistently.
• Downstream maps this to Option; ensure u64→usize uses try_from/try_into (no unchecked as) and add a test for 0, None, and 32‑bit overflow cases.

Suggested proto tweak:

-  optional uint64 max_payload_index_count = 19;
+  optional uint64 max_payload_index_count = 19; // Max number of payload indexes per collection (effective only if strict mode is enabled). Define 0 semantics explicitly.

lib/storage/src/content_manager/conversions.rs (1)

165-166: Avoid lossy u64→usize cast (possible truncation on 32‑bit).

Consider a checked conversion to prevent silent overflow on 32‑bit targets.

-        max_payload_index_count: max_payload_index_count.map(|i| i as usize),
+        max_payload_index_count: max_payload_index_count.and_then(|i| usize::try_from(i).ok()),

If Qdrant only targets 64‑bit, please confirm and we can keep as‑casts for consistency.

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

7452-7458: Add max_payload_index_count to StrictModeConfigOutput — LGTM with a tiny wording fix

Schema, type, and constraints look consistent with the rest of strict-mode fields. Nit: pluralize “index” in the description for clarity.

-          "max_payload_index_count": {
-            "description": "Max number of payload index in a collection",
+          "max_payload_index_count": {
+            "description": "Max number of payload indexes in a collection",
             "type": "integer",
             "format": "uint",
             "minimum": 1,
             "nullable": true
           }

---

10006-10013: Apply pluralization fix to max_payload_index_count description

OpenAPI checks passed; update the description in docs/redoc/master/openapi.json (StrictModeConfig and StrictModeConfigOutput) to "Max number of payload indexes in a collection".

-          "max_payload_index_count": {
-            "description": "Max number of payload index in a collection",
+          "max_payload_index_count": {
+            "description": "Max number of payload indexes in a collection",
             "type": "integer",
             "format": "uint",
             "minimum": 1,
             "nullable": true
           }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: IvanPleshkov
PR: qdrant/qdrant#7043
File: lib/segment/src/vector_storage/quantized/quantized_mmap_storage.rs:86-90
Timestamp: 2025-08-15T11:42:00.297Z
Learning: In lib/segment/src/vector_storage/quantized/quantized_mmap_storage.rs, overflow protection for encoded_storage_size computation (quantized_vector_size * vectors_count) is implemented in PR #7048, using checked_mul with u64 casting to prevent silent overflow.

Learnt from: generall
PR: qdrant/qdrant#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.

tests/openapi/test_strictmode.py (1)

2417-2520: Good coverage for max_payload_index_count; assertions look stable.

Checks enable→enforce→raise limit→enforce→disable flow; fixed prior leading-space issue in error substrings.

Consider adding a follow-up when policy changes: a test for max_payload_index_count=0 (reject or “disabled”) to lock semantics.

lib/api/src/grpc/qdrant.rs (1)

673-734: Strict-mode limits: add validation, clarify 0 vs None semantics, and fix one docstring

• Add validation to prevent accidental “disable everything” by setting 0:
  • max_payload_index_count, upsert_max_batchsize, search_max_hnsw_ef ≥ 1
  • search_max_oversampling ≥ 1.0
• Clarify whether 0 means “disabled/unlimited” or is invalid for all counters (max_query_limit, max_timeout, read_rate_limit, write_rate_limit, max_payload_index_count). If 0 is invalid, add min validations; if it means “unlimited,” document it explicitly.
• Docstring at Line 711 describes “vector storage” but the field is max_collection_payload_size_bytes. Fix the text to “payload storage.”

Apply via proto/build so prost emits the attributes; illustrative diff on the generated struct:

     /// Max HNSW ef value allowed in search parameters.
     #[prost(uint32, optional, tag = "6")]
+    #[validate(range(min = 1))]
     pub search_max_hnsw_ef: ::core::option::Option<u32>,
@@
     /// Max oversampling value allowed in search
     #[prost(float, optional, tag = "8")]
+    #[validate(range(min = 1.0))]
     pub search_max_oversampling: ::core::option::Option<f32>,
@@
     /// Max batchsize when upserting
     #[prost(uint64, optional, tag = "9")]
+    #[validate(range(min = 1))]
     pub upsert_max_batchsize: ::core::option::Option<u64>,
@@
-    /// Max size of a collections vector storage in bytes, ignoring replicas.
+    /// Max size of a collection's payload storage in bytes, ignoring replicas.
     #[prost(uint64, optional, tag = "13")]
     pub max_collection_payload_size_bytes: ::core::option::Option<u64>,
@@
     /// Max number of payload indexes in a collection
     #[prost(uint64, optional, tag = "19")]
+    #[validate(range(min = 1))]
     pub max_payload_index_count: ::core::option::Option<u64>,

lib/api/build.rs (1)

39-54: Use explicit From per guideline (avoid Into::into).

Follow repo style: prefer SomeType::from(x) over x.into().

-        option_env!("GIT_COMMIT_ID").map(Into::into).or_else(|| {
+        option_env!("GIT_COMMIT_ID").map(String::from).or_else(|| {

lib/api/src/grpc/proto/collections.proto (2)

370-370: Fix comment: payload vs vector storage.

The field is max_collection_payload_size_bytes; the comment mentions “vector storage.”

-  optional uint64 max_collection_payload_size_bytes = 13; // Max size of a collections vector storage in bytes, ignoring replicas.
+  optional uint64 max_collection_payload_size_bytes = 13; // Max size of a collection's payload storage in bytes, ignoring replicas.

---

376-376: Wording nit: “indexes” vs “indices.”

Tests and errors use “indices.” Consider unifying wording across API docs/comments.

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

7452-7459: Add StrictModeConfigOutput.max_payload_index_count — looks good; regen from source

Schema shape (integer, uint, min=0, nullable) is fine. Please ensure this JSON was regenerated from the source-of-truth (lib/api/src/rest/schema.rs and/or proto), not edited directly. Also, align nearby description wording with the input schema for consistency:

• search_max_hnsw_ef: Output currently reads “Max HNSW value…”; input says “Max HNSW ef value…”.
• multivector_config/sparse_config: Output uses “configuration”; input uses “strict mode configuration”.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: IvanPleshkov
PR: qdrant/qdrant#7043
File: lib/segment/src/vector_storage/quantized/quantized_mmap_storage.rs:86-90
Timestamp: 2025-08-15T11:42:00.297Z
Learning: In lib/segment/src/vector_storage/quantized/quantized_mmap_storage.rs, overflow protection for encoded_storage_size computation (quantized_vector_size * vectors_count) is implemented in PR #7048, using checked_mul with u64 casting to prevent silent overflow.

Learnt from: generall
PR: qdrant/qdrant#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.

Learnt from: generall
PR: qdrant/qdrant#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
PR: qdrant/qdrant#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.

docs/grpc/docs.md (1)

1599-1600: Doc entry for max_payload_index_count looks good.

Description is concise and clear; aligns with earlier feedback.

lib/api/build.rs (1)

168-176: Missing validation for StrictModeConfig.max_payload_index_count (define >0 or 0-policy).

You added validators for several strict-mode fields but not for max_payload_index_count. Without validation, 0/negative handling is ambiguous across layers. Either enforce >0 here, or clearly define 0 as “disabled” and normalize it in conversions (and tests). This was flagged earlier and still applies.

Apply in this file:

             ("StrictModeConfig.max_points_count", "range(min = 1)"),
             ("StrictModeConfig.read_rate_limit", "range(min = 1)"),
             ("StrictModeConfig.write_rate_limit", "range(min = 1)"),
             ("StrictModeConfig.multivector_config", ""),
             ("StrictModeConfig.sparse_config", ""),
             ("StrictModeSparseConfig.sparse_config", ""),
             ("StrictModeSparse.max_length", "range(min = 1)"),
             ("StrictModeMultivectorConfig.multivector_config", ""),
             ("StrictModeMultivector.max_vectors", "range(min = 1)"),
+            ("StrictModeConfig.max_payload_index_count", "range(min = 1)"),

If 0 should mean “disabled,” don’t add min=1 here; instead, normalize 0→None in the API→internal conversions and document it.

Run to confirm absence/presence across the repo:

#!/bin/bash
rg -n "max_payload_index_count" -C2
rg -nP 'StrictModeConfig\.max_payload_index_count",\s*"range' lib/api/build.rs

lib/api/src/grpc/qdrant.rs (1)

673-737: Add validation (or document & normalize 0 vs None) for StrictModeConfig.max_payload_index_count.

Current state: the generated proto struct (lib/api/src/grpc/qdrant.rs) has no validation; lib/segment/src/types.rs allows 0 (#[validate(range(min = 0))]) and conversions simply cast Some(0) -> 0 (lib/storage/src/content_manager/conversions.rs, lib/api/src/grpc/conversions.rs). src/common/update.rs treats Some(0) as a hard zero-limit (blocking index creation). Either enforce min=1 across the API/type layers or explicitly document that 0 means “disable indices” and change conversions to map 0 -> None consistently.

Apply after regenerating protos (example diff):

-    #[prost(uint64, optional, tag = "19")]
-    pub max_payload_index_count: ::core::option::Option<u64>,
+    #[prost(uint64, optional, tag = "19")]
+    #[validate(range(min = 1))]
+    pub max_payload_index_count: ::core::option::Option<u64>,

Files to touch: lib/api/build.rs (add validation mapping and regenerate), lib/api/src/grpc/qdrant.rs (generated), lib/segment/src/types.rs (align min), and conversion modules (lib/storage/src/content_manager/conversions.rs, lib/api/src/grpc/conversions.rs) if you choose the “0 -> None” semantics.

docs/grpc/docs.md (1)

1590-1590: Tiny wording/grammar polish for consistency.

Prefer these edits (and update the proto comments so regeneration keeps them consistent):

-| upsert_max_batchsize | [uint64](#uint64) | optional | Max batchsize when upserting |
+| upsert_max_batchsize | [uint64](#uint64) | optional | Max batch size when upserting. |

-| max_vectors | [uint64](#uint64) | optional | Max number of vectors in a multivector |
+| max_vectors | [uint64](#uint64) | optional | Max number of vectors in a multi-vector. |

-| max_length | [uint64](#uint64) | optional | Max length of sparse vector |
+| max_length | [uint64](#uint64) | optional | Max length of a sparse vector. |

Also applies to: 1614-1614, 1660-1660

lib/api/src/grpc/qdrant.rs (1)

697-699: Type consistency: consider double (f64) for search_max_oversampling.

QuantizationSearchParams.oversampling is f64; making this double/f64 keeps types aligned across the API. Safe to tweak now before release if wire compatibility is still flexible.

-    #[prost(float, optional, tag = "8")]
-    pub search_max_oversampling: ::core::option::Option<f32>,
+    #[prost(double, optional, tag = "8")]
+    pub search_max_oversampling: ::core::option::Option<f64>,

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: coszio
PR: qdrant/qdrant#7065
File: lib/collection/src/operations/universal_query/shard_query.rs:0-0
Timestamp: 2025-08-15T15:56:36.821Z
Learning: Internal gRPC APIs in Qdrant don't require additional runtime validation when proto-level validation is already configured via build.rs range constraints.

Learnt from: generall
PR: qdrant/qdrant#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.

tests/openapi/test_strictmode.py (2)

2419-2434: Good boundary test for zero limit.

Including max_payload_index_count = 0 validates the lower bound and addresses the prior request to cover this case.

---

2451-2452: LGTM: error substring assertions no longer have stray leading spaces.

Matches the server message precisely and prevents false negatives noted earlier.

Also applies to: 2499-2500, 2537-2538

tests/openapi/test_strictmode.py (3)

2435-2447: Fix misleading comment: no indices allowed here (max=0).

At this point the collection has 0 payload indexes; the failure is due to the limit being 0, not “1 index already”.

-    # should fail now with 1 index already
+    # should fail now because no payload indices are allowed (max=0)

---

2501-2507: Optionally assert config after raising the limit to 2.

Adds a quick GET to confirm the update before proceeding.

     set_strict_mode(collection_name, {
         "enabled": True,
         "max_payload_index_count": 2,
     })
 
+    # verify config reflects the new limit
+    response = request_with_validation(
+        api='/collections/{collection_name}',
+        method="GET",
+        path_params={'collection_name': collection_name},
+    )
+    assert response.ok
+    cfg = response.json()['result']['config']['strict_mode_config']
+    assert cfg['max_payload_index_count'] == 2

---

2539-2542: Optionally assert strict mode is disabled before the final create.

Tiny sanity check prior to the success case.

     set_strict_mode(collection_name, {
         "enabled": False,
     })
 
+    assert not strict_mode_enabled(collection_name)

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro