tests/openapi/test_batch_update_multivec.py (2)

46-50: Stabilize test by avoiding incidental vector-dimension errors

Use a 4D "image" vector (as elsewhere in this suite) so the failure is strictly due to the invalid field condition, not potential dimension checks if validation order changes.

Apply:

-                                "image": [1.0, 0.0, 9.0],
+                                "image": [1.0, 0.0, 9.0, 1.0],

---

65-68: Quieten Ruff S101 in tests and add failure context

Tests commonly use bare asserts; silence S101 locally and include response text for faster diagnosis.

Apply:

-    assert response.status_code == 422
+    assert response.status_code == 422, response.text  # noqa: S101
-    error = response.json()["status"]["error"]
-    assert "Validation error in JSON body" in error
-    assert "At least one field condition must be specified" in error
+    error = response.json()["status"]["error"]
+    assert "Validation error in JSON body" in error  # noqa: S101
+    assert "At least one field condition must be specified" in error  # noqa: S101

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: generall
PR: qdrant/qdrant#7006
File: lib/collection/src/operations/point_ops.rs:501-528
Timestamp: 2025-08-10T18:31:56.855Z
Learning: In Qdrant, batch operations validate that `ids`, `vectors`, and `payloads` (if present) have matching lengths at the REST API level in `lib/api/src/rest/validate.rs` through the `Validate` trait implementation for `Batch`. This validation happens before data is converted to internal structures like `PointInsertOperationsInternal`, so methods operating on these internal structures can safely assume the lengths match.

tests/openapi/test_batch_update_multivec.py (1)

36-64: Consider broadening negative cases (other clauses/ops) to ensure full batch coverage.

Add a couple of variants (e.g., invalid FieldCondition under should/must_not) or mix valid+invalid operations in the same batch to ensure the first failing element is reported and the whole batch is rejected. This complements the note that not all nested variants of Update may be validated deeply.

tests/openapi/test_batch_update_multivec.py (3)

56-56: Clarify the inline comment to reflect why the condition is invalid.

The issue is that FieldCondition lacks any matcher; the payload key name “empty” is incidental.

Apply this diff:

-                                "key": "empty" # empty field conditions are forbidden
+                                "key": "empty"  # invalid FieldCondition: missing any matcher (e.g., match/range); 'key' alone is insufficient

---

65-68: Make assertion less brittle against wording changes in the top-level error wrapper.

The specific phrase “in JSON body” may drift; keep the semantic check but relax wording.

Apply this diff:

-    assert "Validation error in JSON body" in error
+    assert "validation error" in error.lower()

---

65-68: Ruff S101 on asserts in tests: silence or configure per-file ignore.

Asserts are idiomatic in pytest. Either ignore S101 for tests repo-wide or add a per-file override.

Add at the top of this test file:

# ruff: noqa: S101

Or in pyproject.toml:

[tool.ruff.lint.per-file-ignores]
"tests/**" = ["S101"]

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: generall
PR: qdrant/qdrant#7006
File: lib/collection/src/operations/point_ops.rs:501-528
Timestamp: 2025-08-10T18:31:56.855Z
Learning: In Qdrant, batch operations validate that `ids`, `vectors`, and `payloads` (if present) have matching lengths at the REST API level in `lib/api/src/rest/validate.rs` through the `Validate` trait implementation for `Batch`. This validation happens before data is converted to internal structures like `PointInsertOperationsInternal`, so methods operating on these internal structures can safely assume the lengths match.