[nick-boss-tech]

🤖 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 with no approximateTotalHits header, and invert the exactness flag.

In CombinedQueryComponent.mergeIds, a shard's totals are added before the partial-results skip is tested (lines 342 to 343, lines 399 to 400). A skipped shard still adds its hits. With fabricated shard responses, the merged numFound was 7 where 3 documents were merged, and approximateTotalHits was 15 instead of 5. A shard with no approximateTotalHits header falls back to the running merged total, so two shards merge to 7 instead of 5. The exactness fold is inverted: all-exact merges report false, and all-inexact merges report true.

What this change does

The skip is tested before any total is added, the fallback uses the shard's own count, and numFoundExact is cleared when a shard is skipped or more than one sub-query contributes.

The skip now sits above the totals in the same loop (lines 389 to 467). A skipped shard adds nothing to numFound or approximateTotalHits, but it still clears numFoundExact, because it may hold unreported matches. With more than one contributing sub-query, numFoundExact is cleared even if every count is exact. numFound still keeps the largest sub-query count.

Proof

Nine tests in CombinedQueryComponentMergeTotalsTest pass at head 81a88e40dd42f90fe6c67b2aeb6f678c437d7c0d (verified 2026-10-16). Six of them fail on the base code.

• Base (merge-base 597ed6774083, branch test file in place): 9 tests, 6 failures. skippedPartialShardApproximateTotalExcluded (approximateTotalHits 15, expected 5), fallbackUsesEachShardsOwnCount (7, expected 5), skippedPartialShardContributesNothing (numFound 7, expected 3), skippedPartialShardWithHitsClearsExactness (numFound 2, expected 0), and two single-sub-query exactness tests, where the base fold inverts numFoundExact.
• Three tests pass on base only because of the inverted fold, so they are not fail-before proof.
• Prior head a93f9f6a997e: exactly one failure, multipleContributingSubQueriesClearExactness (numFoundExact expected:<false> but was:<true>). It is the discriminating test.

A choice to check

This choice is answered on the ticket: numFoundExact is false when more than one sub-query contributes. The distinct-document count is a follow-up.

numFound keeps the largest sub-query count. The alternative, counting distinct matching documents, is a follow-up. On the ticket, the maintainer directed the minimum change: clear numFoundExact when more than one sub-query contributes.

Limits

The tests use fabricated shard responses. One defect from a real timeAllowed exit is not fixed here.

• A real timeAllowed exit after the first sub-query leaves a shorter list. The merge then throws IndexOutOfBoundsException at the unchecked access (lines 338 to 340). This change leaves that access alone, and the run was not repeated at this head. A size check would fix it.
• QueryAndResponseCombiner.simpleCombine takes the largest sub-query count as its total (Math.max). This change leaves it alone. The maintainer named it as having the same cause on main.

Changelog: 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.

[ercsonusharma]

Thanks @nick-boss-tech, these are good fixes. I'd like to come back to this once SOLR-18550 is merged and this is rebased on top, since both changes how numFound/numFoundExact are computed for combined queries. Some piece of code will likely need adjusting after that.

[punAhuja]

@nick-boss-tech @ercsonusharma — following up on the sequencing: #5172 (SOLR-18550) is updated per review with the interim numFound semantics and Sonu's numFoundExact handling. Once it merges, the exactness-fold fix here should rebase cleanly on top — both PRs fixed the same inverted fold, so that line drops to one copy. Happy to help with any conflicts in that rebase.