test: reproduce MatchAny(any=[]) strict-mode rejection on integer index by qdrant-cloud-bot · Pull Request #9260 · qdrant/qdrant

qdrant-cloud-bot · 2026-06-02T06:13:44Z

Summary

Reproduces a strict-mode bug where FieldCondition(key=\"f\", match=MatchAny(any=[])) on an integer-indexed payload field is rejected with:

Bad request: Index required but not found for "n" of one of the following types: [keyword, uuid]. Help: Create an index for this key or use a different filter.

even though the field has an integer payload index. Replacing any=[] with any=[1] succeeds.

Root cause (analysis)

AnyVariants in lib/segment/src/types.rs is #[serde(untagged)] with the Strings variant listed first, so an empty [] deserializes as AnyVariants::Strings(∅). Over gRPC, an empty MatchAny is serialized by the Python client as Match { keywords: RepeatedStrings { strings: [] } }, which also maps to AnyVariants::Strings(∅) in lib/api/src/grpc/conversions.rs.

Strict mode then infers the required index type purely from the variant tag in lib/collection/src/problems/unindexed_field.rs::infer_index_from_any_variants — without checking whether the list is empty — and demands a keyword/uuid index.

At the execution layer the condition already behaves as a no-op (matches nothing) thanks to the _ => false fall-through in condition_checker.rs, so the strict-mode pre-check is the only place where the empty case is mis-handled.

Expected: an empty MatchAny/MatchExcept should be a no-op for strict mode regardless of the field's index type (or, failing that, not infer a keyword/uuid requirement out of nothing).

What this PR contains

Only a new test file tests/openapi/test_match_any_empty.py (no fix) so the bug is captured and CI tracks it. The file mirrors the existing test_match_except_empty.py and adds three strict-mode reproductions:

test_match_any_empty_with_strict_mode_integer_index — plain must filter
test_match_any_empty_with_strict_mode_in_must_not — must_not filter
test_match_any_empty_with_strict_mode_in_formula_query — FormulaQuery FieldCondition

Locally, baseline tests pass (12) and the three strict-mode tests fail with the exact reported error message, confirming reproduction.

Test plan

pytest tests/openapi/test_match_any_empty.py -v — baseline tests pass, strict-mode tests fail with Index required but not found for \"n\" of one of the following types: [keyword, uuid] (matches the report).
After a follow-up fix, all 15 tests should pass.

Related to #9050 (analogous behaviour exists for MatchExcept(except=[]), already tested in test_match_except_empty.py).

Made with Cursor

Adds an openapi test that demonstrates the strict-mode bug where `match: {"any": []}` on an integer-indexed payload field is rejected with: Bad request: Index required but not found for "<field>" of one of the following types: [keyword, uuid] even though the field is indexed as integer. Root cause is that an empty `any` list deserializes as `AnyVariants::Strings(empty)` (untagged enum; Strings variant listed first), and strict mode infers a keyword/uuid index requirement from the variant tag — ignoring that the list is empty (i.e. a no-op condition). The test covers: - Baseline no-op semantics with and without indexes (passes today). - Reproduction under strict mode for `must`, `must_not`, and a FormulaQuery FieldCondition (currently failing; will pass once empty `any`/`except` no longer requires an index). Co-authored-by: Cursor <[email protected]>

coderabbitai · 2026-06-02T06:14:01Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro

Run ID: 13bcfe53-40e1-4f4c-a844-c22561e977f3

📥 Commits

Reviewing files that changed from the base of the PR and between 90dbc0f and 886ce9f.

📒 Files selected for processing (1)

lib/collection/src/problems/unindexed_field.rs

📝 Walkthrough

Walkthrough

This pull request adds pytest tests that validate MatchAny(any=[]) behavior across unindexed and indexed integer/keyword/uuid fields, plus strict-mode regression tests covering must, must_not, and formula-query placements. It also updates Rust logic to treat empty Any/Except variants as no-ops and to skip unindexed-field inference when no index is required.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested reviewers

agourlay
generall

Poem

🐰 I hopped through tests both strict and free,
Empty any lists matched nowhere to be,
Indexes checked and guards applied,
Bugs chased out, then cast aside,
A carrot-coded cheer for stability 🥕

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 8.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: adding a test that reproduces a MatchAny strict-mode rejection bug on integer indexes.
Description check	✅ Passed	The description is well-detailed and directly related to the changeset, explaining the bug reproduction, root cause analysis, and what the PR contains.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

Create stacked PR
Commit on current branch

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

coderabbitai

🧹 Nitpick comments (1)

tests/openapi/test_match_any_empty.py (1)

102-109: ⚡ Quick win

Inconsistent error handling pattern.

All other helpers in this file use assert response.ok for validation, but _set_strict_mode uses response.raise_for_status(). While both approaches work, consistency improves maintainability.

♻️ Align with the pattern used by other helpers

 def _set_strict_mode(collection_name, strict_mode_config):
     response = request_with_validation(
         api="/collections/{collection_name}",
         method="PATCH",
         path_params={"collection_name": collection_name},
         body={"strict_mode_config": strict_mode_config},
     )
-    response.raise_for_status()
+    assert response.ok

🤖 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/openapi/test_match_any_empty.py` around lines 102 - 109, The helper
_set_strict_mode currently calls response.raise_for_status(); change it to
follow the file's consistent pattern by replacing that call with an assertion
using assert response.ok (and optionally include a message), so the function
aligns with other helpers' error handling style.

🤖 Prompt for all review comments with 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.

Nitpick comments:
In `@tests/openapi/test_match_any_empty.py`:
- Around line 102-109: The helper _set_strict_mode currently calls
response.raise_for_status(); change it to follow the file's consistent pattern
by replacing that call with an assertion using assert response.ok (and
optionally include a message), so the function aligns with other helpers' error
handling style.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro

Run ID: a5e4a6d7-1d7b-4085-99c0-34c83865682b

📥 Commits

Reviewing files that changed from the base of the PR and between e0d9489 and 90dbc0f.

📒 Files selected for processing (1)

tests/openapi/test_match_any_empty.py

…heck An empty `match: {"any": []}` (or `{"except": []}`) is a no-op: `any: []` matches nothing and `except: []` excludes nothing, regardless of the field's data type. Because an empty list cannot carry type information it deserializes as the keyword `AnyVariants::Strings(empty)` variant, which previously caused strict mode to demand a keyword/uuid index and reject the request with: Index required but not found for "<field>" of one of the following types: [keyword, uuid] even on a field indexed as integer. Fix: - `infer_index_from_any_variants` returns no required index for an empty variant set. - `Extractor::update_from_condition` skips a condition whose required index set is empty, so a no-op condition is never reported as needing an index (this also covers the FormulaQuery condition path). This makes the openapi reproduction in test_match_any_empty.py pass. Co-authored-by: Cursor <[email protected]>

qdrant-cloud-bot · 2026-06-02T06:35:04Z

Added the fix as a follow-up commit (886ce9f).

Fix (lib/collection/src/problems/unindexed_field.rs):

infer_index_from_any_variants now returns no required index for an empty any/except set.
Extractor::update_from_condition skips conditions with an empty required-index set, so a no-op condition is never reported as needing an index. This also covers the FormulaQuery condition path (which delegates to update_from_condition).

An empty MatchAny/MatchExcept is a no-op (matches nothing / excludes nothing) at the execution layer regardless of field type, so strict mode should not demand an index for it.

Verification:

All 15 tests in test_match_any_empty.py now pass (previously 3 strict-mode cases failed with the reported error).
No regressions: test_match_except_empty.py + test_strictmode.py (62 passed), and the unindexed_field unit test passes.

…ex (#9260) * test: reproduce MatchAny(any=[]) strict-mode rejection on integer index Adds an openapi test that demonstrates the strict-mode bug where `match: {"any": []}` on an integer-indexed payload field is rejected with: Bad request: Index required but not found for "<field>" of one of the following types: [keyword, uuid] even though the field is indexed as integer. Root cause is that an empty `any` list deserializes as `AnyVariants::Strings(empty)` (untagged enum; Strings variant listed first), and strict mode infers a keyword/uuid index requirement from the variant tag — ignoring that the list is empty (i.e. a no-op condition). The test covers: - Baseline no-op semantics with and without indexes (passes today). - Reproduction under strict mode for `must`, `must_not`, and a FormulaQuery FieldCondition (currently failing; will pass once empty `any`/`except` no longer requires an index). Co-authored-by: Cursor <[email protected]> * fix: treat empty MatchAny/MatchExcept as no-op in strict-mode index check An empty `match: {"any": []}` (or `{"except": []}`) is a no-op: `any: []` matches nothing and `except: []` excludes nothing, regardless of the field's data type. Because an empty list cannot carry type information it deserializes as the keyword `AnyVariants::Strings(empty)` variant, which previously caused strict mode to demand a keyword/uuid index and reject the request with: Index required but not found for "<field>" of one of the following types: [keyword, uuid] even on a field indexed as integer. Fix: - `infer_index_from_any_variants` returns no required index for an empty variant set. - `Extractor::update_from_condition` skips a condition whose required index set is empty, so a no-op condition is never reported as needing an index (this also covers the FormulaQuery condition path). This makes the openapi reproduction in test_match_any_empty.py pass. Co-authored-by: Cursor <[email protected]> --------- Co-authored-by: Cursor <[email protected]>

coderabbitai Bot reviewed Jun 2, 2026

View reviewed changes

generall approved these changes Jun 2, 2026

View reviewed changes

generall merged commit d7b6713 into dev Jun 2, 2026
21 of 22 checks passed

generall deleted the test/match-any-empty-strict-mode branch June 2, 2026 08:27

timvisee mentioned this pull request Jun 3, 2026

Bump version to 1.18.2 #9290

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

test: reproduce MatchAny(any=[]) strict-mode rejection on integer index#9260

test: reproduce MatchAny(any=[]) strict-mode rejection on integer index#9260
generall merged 2 commits into
devfrom
test/match-any-empty-strict-mode

qdrant-cloud-bot commented Jun 2, 2026

Uh oh!

coderabbitai Bot commented Jun 2, 2026 •

edited

Loading

Walkthrough

Estimated code review effort

Suggested reviewers

Poem

❌ Failed checks (1 warning)

Uh oh!

coderabbitai Bot left a comment

Uh oh!

qdrant-cloud-bot commented Jun 2, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

qdrant-cloud-bot commented Jun 2, 2026

Summary

Root cause (analysis)

What this PR contains

Test plan

Uh oh!

coderabbitai Bot commented Jun 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Estimated code review effort

Suggested reviewers

Poem

❌ Failed checks (1 warning)

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

qdrant-cloud-bot commented Jun 2, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

coderabbitai Bot commented Jun 2, 2026 •

edited

Loading