[
https://issues.apache.org/jira/browse/SOLR-18541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127739#comment-18127739
]
Nick Shanin commented on SOLR-18541:
------------------------------------
AI-generated, human-reviewed text below.
Thank you for the reproduction and the clear direction. The minimum change is
in PR #5117 at head \{{81a88e40dd}}: \{{CombinedQueryComponent.mergeIds}}
counts the sub-queries that contribute to a merge and reports
\{{numFoundExact=false}} whenever more than one contributes. \{{numFound}}
still keeps the largest sub-query count, and single-sub-query merges are
unchanged.
The two \{{largestSubQueryTotalWins*}} tests are dropped. A new test in the
shape of your repro (exact counts of 3 and 2, five documents returned,
\{{numFound}} 3) fails against the previous head with \{{numFoundExact=true}}
and passes now; the class passes 9 of 9 at the new head.
The union count as a follow-up Jira would be welcome. One note for it:
\{{QueryAndResponseCombiner.simpleCombine}} carries the same maximum rule and
is outside this PR, so the follow-up may want to cover both merge sites.
> CombinedQueryComponent.mergeIds gives wrong numFound, approximateTotalHits
> and numFoundExact
> --------------------------------------------------------------------------------------------
>
> Key: SOLR-18541
> URL: https://issues.apache.org/jira/browse/SOLR-18541
> Project: Solr
> Issue Type: Bug
> Components: query
> Reporter: Nick Shanin
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 🤖 _AI text below_ 🤖 _(posted on behalf of Nick Shanin)_
> Combined queries merge their per-query shard results in
> {{CombinedQueryComponent.mergeIds}}, and three defects sit in the totals that
> merge reports. First, a partial shard that sends a per-query entry is counted
> in that query's totals before the partial skip is tested, so its documents
> are dropped but its hits are not: in a constructed partial-response case run
> on unmodified main, the merged {{numFound}} was 7 instead of 3 and
> {{approximateTotalHits}} was 15 instead of 5. Second, when a shard sends no
> {{approximateTotalHits}} header, the fallback adds the running per-query
> total, which already includes the current shard, so two shards with 2 and 3
> documents merged to 7 instead of 5. Third, the {{hitCountIsExact}} fold is
> inverted: an all-exact merge reports {{numFoundExact=false}} and an
> all-inexact merge reports true, both confirmed by run on unmodified main.
> The fix I recommend is to test the skip before accumulating, with the other
> two corrections in the same change: the fallback should add the shard's own
> count instead of the running total, and the fold should keep the merged flag
> true only when every shard reports its count exact. Correcting the totals
> after the skip fires instead would mean reconstructing what the skipped shard
> added, and the exactness fold cannot be un-folded without per-shard tracking.
> One question for the maintainer: when several sub-queries contribute,
> {{numFound}} is currently the largest single sub-query count; should it
> instead count the distinct documents that match any sub-query, and should
> {{numFoundExact}} be false whenever more than one sub-query contributes?
> AI agents assisted with research, implementation, review, and drafting. Nick
> Shanin directed the work and takes responsibility for the above text.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
