fix(qdrant): apply all filter operators when multiple operators target the same field

[Fazlul105]

Description

Fixes #7468

When filtering memories in the Qdrant vector store with multiple operators targeting the same field (either passed directly such as {"status": {"ne": "archived", "nin": ["deleted"]}} or produced when Memory._process_metadata_filters merges single-field AND clauses), _build_field_condition in mem0/vector_stores/qdrant.py previously evaluated match operators using an elif chain and returned only the first matching FieldCondition, silently dropping all remaining operators on that field. Additionally, combining range and non-range operators on the same field dictionary raised a ValueError even when merged via AND.

Changes Made

• mem0/vector_stores/qdrant.py:
  • Updated _build_field_condition to evaluate all non-range match operators (eq, ne, in, nin, contains, icontains) independently rather than stopping at the first elif branch, returning a single FieldCondition when one condition is present (preserving backward compatibility) or a list of FieldConditions when multiple operators are specified.
  • Updated _create_filter to split mixed range + non-range operator dictionaries on the same field into their respective FieldConditions and append all resulting conditions to must.
• tests/vector_stores/test_qdrant.py:
  • Added TestQdrantEveryOperatorOnAField covering multi-operator match filters (ne + nin, contains + icontains), mixed range + match filters (gte + ne), and AND-merged single-field filters against an in-memory QdrantClient(":memory:").

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (does not change functionality, e.g. code style improvements, linting)
• Documentation update

How Has This Been Tested?

• Ran pytest tests/vector_stores/test_qdrant.py tests/vector_stores/test_qdrant_config.py -v locally (104 passed).
• Ran ruff check and ruff format --check on all modified files.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have checked my code and corrected any misspellings

AI Disclosure: Assisted by Antigravity IDE for test scaffolding; all changes and in-memory Qdrant tests reviewed and verified locally.

[CLAassistant]

All committers have signed the CLA.

[github-actions]

Hi @Fazlul105, thanks for opening this pull request.

This is just a soft check: you are not yet in this repo's vouched contributor list (.github/VOUCHED.td). Nothing is blocked and there is nothing you need to do.

A maintainer can vouch for you by commenting !vouch @Fazlul105 on any issue.

[github-actions]

Thanks for taking the time to open this.

We only review pull requests that fix an issue we have already agreed to take on, so this one is closed for now.
Closed does not mean rejected. It means it is not in the queue yet, and reopening takes about a minute.

To get it reviewed:

1. Make sure an issue describes the problem, with the version you are on, a runnable reproduction, and the real output or traceback you saw.
2. Link it from this pull request description with Closes #<number>.
3. Ask a maintainer to label that issue accepted. This pull request reopens by itself when they do.

Issue already labeled accepted? Just add Closes #<number> to the description. That reopens this too.

Documentation-only changes skip this gate entirely.

See CONTRIBUTING.md for the full policy.