nick-boss-tech opened a new pull request, #5117: URL: https://github.com/apache/solr/pull/5117
🤖 *AI text below* 🤖 *(posted on behalf of Nick Shanin)* https://issues.apache.org/jira/browse/SOLR-18541 ## What happens today **Combined queries report totals that count shards the merge dropped, double-count shards that send no approximateTotalHits header, and invert the exactness flag.** In `CombinedQueryComponent.mergeIds`, a shard's totals are folded into its query's totals before the partial-results skip is tested. At the merge-base, the numFound and exactness folds run at [lines 342 to 343](https://github.com/nick-boss-tech/solr/blob/597ed67740831566b708b793f52554b2e49e7e17/solr/core/src/java/org/apache/solr/handler/component/CombinedQueryComponent.java#L342-L343) and the approximate total block at [lines 381 to 387](https://github.com/nick-boss-tech/solr/blob/597ed67740831566b708b793f52554b2e49e7e17/solr/core/src/java/org/apache/solr/handler/component/CombinedQueryComponent.java#L381-L387), while the skip is only tested at [lines 399 to 400](https://github.com/nick-boss-tech/solr/blob/597ed67740831566b708b793f52554b2e49e7e17/solr/core/src/java/org/apache/solr/handler/component/CombinedQueryComponent.java#L399-L400). A partial shard that is skipped for a query has already added its hits to that query: with fabricated shard responses, the merged numFound was 7 where 3 documents were merged, and approximateTotalHits was 15 instead of 5. When a shard sends no approximateTotalHits header, the fallback adds the running merged total, which already includes that shard, so two shards with 2 and 3 documents merge to an approximate total of 7 instead of 5. The exactness fold keeps the merged flag true only while shards report their counts as not exact, so an all-exact merge reports numFoundExact as false and an all-inexact merge reports it as true. ## What this change does **The skip is tested before any total is folded in, the fallback adds the shard's own count, and the exactness fold follows the form QueryComponent uses.** The skip now sits above the totals in the same (query, shard) iteration, at [lines 389 to 408](https://github.com/nick-boss-tech/solr/blob/d5ed34125db9582b584bbfdd149a4de4b40650d0/solr/core/src/java/org/apache/solr/handler/component/CombinedQueryComponent.java#L389-L408). A skipped shard contributes nothing to that query's numFound, approximateTotalHits or exactness. A shard with no approximateTotalHits header adds its own per-query count, and 0 when it sent no per-query entry. The exactness fold starts from true and is cleared when a contributing shard reports its count as not exact. How documents are merged, and how the per-query totals combine across sub-queries, do not change. ## Proof **The new test class fails on the base code with the wrong totals above and passes with this change: 7 of 7.** `CombinedQueryComponentMergeTotalsTest` drives fabricated shard responses through mergeIds. On the base production code all 7 tests fail: numFound 7 instead of 3, approximateTotalHits 15 instead of 5, 7 instead of 5 and 21 instead of 11, and numFoundExact inverted in both directions. With this change all 7 pass. Verified 2026-10-12 at this head. ## A choice to check **This change keeps the current rule that the combined numFound is the largest single sub-query count. The alternative is to count the distinct documents that match any sub-query.** The per-query totals still combine by maximum, so numFound can be smaller than the number of distinct documents the sub-queries match together: two disjoint sub-queries with two hits each return four documents while numFound is 2. The merged approximateTotalHits passes through the same maximum. In the two multi-query cases in the new test, per-query approximate totals of 5 and 11 merge to 11, and totals of 5 and 2 merge to 5; on the base code the fallback error inflated those merged values to 21 and 7. I kept the maximum because what numFound should mean for a combined query is a wider decision than the three defects in the ticket, and the new tests pin the current behavior so a change would be visible. Should numFound instead report the distinct documents that match any sub-query, and should numFoundExact be false whenever more than one sub-query contributes? ## Limits **What this change does not settle is named here.** The tests drive the merge with fabricated shard responses; they do not reproduce a real shard's timeAllowed exit. Code reading says a real exit of the settled shape sends no per-query entry for the unprepared query, so the skip defect needs the constructed response shape the tests use; the fallback and exactness defects need no partial results at all. Two nearby gaps are left as they are: the merge reads a shard's per-query list with no size check, and a shard with no per-query entry can reach the document loop under a score-only sort. A follow-up can take either up on request. What numFoundExact should report when several sub-queries contribute is part of the choice above; this change settles the single-sub-query case. Changelog: [changelog/unreleased/SOLR-18541-combined-query-merge-totals.yml](https://github.com/nick-boss-tech/solr/blob/d5ed34125db9582b584bbfdd149a4de4b40650d0/changelog/unreleased/SOLR-18541-combined-query-merge-totals.yml) ### AI assistance AI agents assisted with research, implementation, review, and drafting. Nick Shanin directed the work and takes responsibility for this contribution. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
