fix(opensearch): don't merge same-field ranges under OR

[chuenchen309]

The bug

Both the top-level _parse_logical_condition and the nested-field grouping call _normalize_ranges for every multi-condition group:

if len(conditions) > 1:
    conditions = _normalize_ranges(conditions)

_normalize_ranges merges range clauses on the same field into one (via dict.update). That's correct for AND — price > 10 AND price < 100 should become one {"gt": 10, "lt": 100} range. But it also runs for OR, where it's wrong:

{
    "operator": "OR",
    "conditions": [
        {"field": "meta.price", "operator": "<", "value": 10},
        {"field": "meta.price", "operator": ">", "value": 100},
    ],
}

renders as:

{"bool": {"should": [{"range": {"price": {"lt": 10, "gt": 100}}}]}}

A single range clause with both lt: 10 and gt: 100 means price < 10 AND price > 100, which matches no document — even though the user asked for price < 10 OR price > 100. The same collapse happens inside nested-field groups (_group_nested_conditions), dropping a bound of an OR of ranges on a nested sub-field.

This is a sibling of the pgvector/elasticsearch range handling; the correct output keeps two separate range clauses in should.

The fix

Only merge ranges when the conditions are AND-combined, at both sites (top level and nested groups). AND and the inner must of NOT keep merging; OR skips it:

if len(conditions) > 1 and operator != "OR":
    conditions = _normalize_ranges(conditions)

Tests

Added two regression tests:

• test_or_of_ranges_on_same_field_are_not_merged — top-level OR of two same-field ranges stays two separate range clauses.
• test_or_of_ranges_on_same_nested_field_are_not_merged — same, inside a nested-field group.

Both fail before the change (ranges collapse into one impossible range) and pass after. I verified each fix site is load-bearing (reverting the nested guard alone makes the nested test fail).

Verified locally: hatch run test:unit passes (167 passed), hatch run fmt and hatch run test:types are clean.

---

Authored with AI assistance (Claude Code); the change and tests were reviewed and verified locally by me.

[github-actions]

Coverage report (pgvector)

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
integrations/pgvector/src/haystack_integrations/document_stores/pgvector
filters.py					230-231
Project Total

This report was generated by python-coverage-comment-action

[github-actions]

Coverage report (chroma)

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
integrations/chroma/src/haystack_integrations/document_stores/chroma
filters.py					68, 74
Project Total

This report was generated by python-coverage-comment-action

[github-actions]

Coverage report (opensearch)

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
integrations/opensearch/src/haystack_integrations/document_stores/opensearch
filters.py
Project Total

This report was generated by python-coverage-comment-action

[github-actions]

Coverage report (elasticsearch)

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
integrations/elasticsearch/src/haystack_integrations/document_stores/elasticsearch
filters.py
Project Total

This report was generated by python-coverage-comment-action