[akshit-khandelwal47]

Related Issues

• fixes SolrDocumentStore: numeric filters drop documents when metadata mixes ints and floats #4083

Proposed Changes:

An int and a float of the same metadata key are stored in different fields (meta_l_<key> and meta_d_<key>), and a filter only queried the field matching the type of its own value. Mixed int/float metadata, which is what JSON gives you, lost documents on every numeric operator.

Numeric ==, !=, ranges, in and not in now query both fields:

• rating == 5 becomes (meta_l_rating:5 OR meta_d_rating:5). A fractional value such as 4.5 only targets meta_d_, since no int can equal it.
• plong rejects a fractional bound, so for ranges the int field is compared with the nearest whole number the range still admits, inclusively: > 4.5 becomes meta_l_rating:[5 TO *] on the int side, < 4.5 becomes [* TO 4].
• id, content, strings, bools and non-finite floats keep the existing single-field clauses.

How did you test it?

• New integration test test_numeric_filters_match_ints_and_floats_alike writes ratings [-1.5, -1, 3, 4, 4.5, 5, 5.0] and checks 13 filters against InMemoryDocumentStore on the same documents. 12 of them fail on main.
• New unit tests for the rounding, whole floats (5.0), in with mixed values, and the inf case.
• 16 existing unit tests pinned the old single-field clause strings; I updated their expected values.
• hatch run test:all against Solr 10.0.0 from the integration's compose setup: 543 passed, 4 skipped. hatch run fmt-check and hatch run test:types pass.

Notes for the reviewer

List-valued metadata is not changed here. [4, 4.5] is stored as JSON because the element types differ, and == [4, 5] against a stored [4.0, 5.0] still does not match. It is the same class of problem on a different code path, so I left it out of this PR. Happy to open a separate issue for it.

AI disclosure: I used Claude Code to help write this change and its tests. I reviewed every line and ran the tests above myself.

Checklist

• I have read the contributors guidelines and the code of conduct
• I added unit tests and updated the docstrings
• I've used one of the conventional commit types for my PR title: fix:, feat:, build:, chore:, ci:, docs:, style:, refactor:, perf:, test:.

[github-actions]

Coverage report (solr)

Click to see where and how coverage changed

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

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

[HaystackBot]

Hi @akshit-khandelwal47, thanks a lot for your contribution! 🙏

We noticed that the Contributor License Agreement (CLA) check (license/cla) hasn't passed yet, so we've temporarily moved this PR to draft and paused the review assignment.

To get your PR reviewed, please sign the CLA via the link in the license/cla check below (or in the CLA bot comment). As soon as the check turns green, this PR will automatically be marked ready for review again and a reviewer will be re-assigned.

[akshit-khandelwal47]

The CLA check hasn't run on this PR, so there is nothing for me to sign yet. When I tried to sign at cla-assistant.io on 2026-10-29 it returned "Bad credentials", and other PRs opened since Oct 28 (#4171 here, deepset-ai/haystack#13481 to #13483) have no license/cla status either. Could someone re-trigger the check once the CLA Assistant is working again? I'll sign as soon as it shows up.