Thanks for pointing that issue out. ________________________________ From: Amrit Sarkar <[email protected]> Sent: Friday, 16 October 2026 21:58:44 To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; Justin Michael Coyne <[email protected]> Subject: Re: Re: CombinedQuerySearchHandler and numFound
Hi Puneet, Justin, This one is already tracked in SOLR-18541 (Nick Shanin, PR #5117). I reproduced Justin's report on the RC2 tarball last night and posted the details there: https: //www. google. com/url?q=https: //issues. apache. org/jira/browse/SOLR-18541?focusedCommentId%3D18127698%23comment-18127698&source=gmail&ust=1792292324548000&sa=E Hi Puneet, Justin, This one is already tracked in SOLR-18541 (Nick Shanin, PR #5117). I reproduced Justin's report on the RC2 tarball last night and posted the details there: https://www.google.com/url?q=https://issues.apache.org/jira/browse/SOLR-18541?focusedCommentId%3D18127698%23comment-18127698&source=gmail&ust=1792292324548000&sa=E<https://urldefense.com/v3/__https://www.google.com/url?q=https:**Aissues.apache.org*jira*browse*SOLR-18541*focusedCommentId*3D18127698*23comment-18127698&source=gmail&ust=1792292324548000&sa=E__;Ly8vLy8_JSU!!G92We9drHetJ8EofZw!aIVH-8yjnszmrstTojvjLBsEb1vyGWXCUCnL6pHzezhXxid34O4lsISuyQVumTJ-tr93hlN6c2wYRV9yAL0m0cZDFow$> Nick has since updated #5117 so numFoundExact is false whenever more than one sub-query contributes, and asked for the union count as a follow-up, which I'd offered to take. SOLR-18550 covers the same ground, and #5117 and #5172 change the same exactness line in mergeIds, so let's pick one home and link the other. One concern with #5172: numFound becomes the size of the fused pool. Once a sub-query has more matches than start+rows (or shards.rows), that's well below what we report today. A query with 1000 hits at rows=10 would go from numFound=1000 to about 20, so a paging UI shows 2 pages. It's marked inexact, but it's still a step back for the common case. An exact count is doable. Shards don't share docs, so each shard can report its own union count (simpleCombine already builds that DocSet union when faceting is on) and the coordinator sums them. That matches /select. The cost is a DocSet per sub-query on every combined request, which a maintainer should weigh in on. Happy to work on this together. Puneet, if you want to keep driving it on SOLR-18550, I'll review and help with the shard side. Otherwise I'll pick it up as the follow-up Nick suggested. Amrit On Fri, Oct 16, 2026 05:36 AM, Puneet Ahuja <[email protected]<mailto:[email protected]>> wrote: Hi Justin, Thanks for the writeup. I actually ran into the same bug a few days back while working on the RRF weights change ( https://github.com/apache/solr/pull/5119<https://urldefense.com/v3/__https://github.com/apache/solr/pull/5119__;!!G92We9drHetJ8EofZw!aIVH-8yjnszmrstTojvjLBsEb1vyGWXCUCnL6pHzezhXxid34O4lsISuyQVumTJ-tr93hlN6c2wYRV9yAL0mIonKmpE$>), so this was on my list to fix anyway. The cause is in CombinedQueryComponent.mergeIds: numFound ends up as the bigger sub-query's count instead of the fused one, and the numFoundExact check is inverted, which is why your all-exact example shows false. I have filed a JIRA(https://issues.apache.org/jira/browse/SOLR-18550<https://urldefense.com/v3/__https://issues.apache.org/jira/browse/SOLR-18550__;!!G92We9drHetJ8EofZw!aIVH-8yjnszmrstTojvjLBsEb1vyGWXCUCnL6pHzezhXxid34O4lsISuyQVumTJ-tr93hlN6c2wYRV9yAL0miobZRYA$>) and will raise a PR on main with the fix shortly. Your repro would make a good test case, so I'll fold it in. Happy to review with you or have you review the patch. I've credited you as the reporter in the JIRA and the changelog. Puneet On Fri, Oct 16, 2026 at 2:28 AM Justin Michael Coyne via dev < [email protected]<mailto:[email protected]>> wrote: > I was working with CombinedQuerySearchHandler (in solr 10.1.0.rc2) today > and noticed that it reports numFound as the largest sub-query's hit count, > not the size of the fused result. Shouldn't it instead be the number of > distinct documents in the combined result, which is the union of the > sub-queries? > > Here's a reproduction: > > SOLR=http://localhost:8983/solr/demo<https://urldefense.com/v3/__http://localhost:8983/solr/demo__;!!G92We9drHetJ8EofZw!aIVH-8yjnszmrstTojvjLBsEb1vyGWXCUCnL6pHzezhXxid34O4lsISuyQVumTJ-tr93hlN6c2wYRV9yAL0mcCrWpoM$> > > curl -s "$SOLR/config" -H 'Content-Type: application/json' -d '{ > "add-searchcomponent": {"name": "combined_query", "class": > "solr.CombinedQueryComponent"}, > "add-requesthandler": {"name": "/hybrid", "class": > "solr.CombinedQuerySearchHandler"} > }' > 3 cat docs, 2 dog docs, no overlap > curl -s "$SOLR/update?commit=true" -H 'Content-Type: application/json' -d > '[ > {"id": "1", "subject_s": "cat"}, > {"id": "2", "subject_s": "cat"}, > {"id": "3", "subject_s": "cat"}, > {"id": "4", "subject_s": "dog"}, > {"id": "5", "subject_s": "dog"} > ]' > > > curl -s "$SOLR/hybrid" -H 'Content-Type: application/json' -d '{ > "queries": { > "cats": {"lucene": {"query": "subject_s:cat"}}, > "dogs": {"lucene": {"query": "subject_s:dog"}} > }, > "params": { > "combiner": true, > "combiner.query": ["cats", "dogs"], > "combiner.algorithm": "rrf", > "fl": "id", > "rows": 10 > } > }' > > > Expected > `numFound: 5`, the same as `/select?q=subject_s:cat OR subject_s:dog`, > which returns `numFound: 5, numFoundExact: true`. > Actual > {"response": {"numFound": 3, "start": 0, "numFoundExact": false, > "docs": [{"id": "4"}, {"id": "1"}, {"id": "5"}, {"id": "2"}, {"id": "3"}]}} > > The response returns five documents but reports `numFound: 3`. >
