DisjunctionMaxQuery with tie-breaker 0 scores NaN instead of +Infinity when two clauses score +Infinity

With tie-breaker 0, DisjunctionMaxQuery should score a document with the maximum of its matching clauses' scores. DisjunctionMaxScorer.score instead computes scoreMax + otherScoreSum * tieBreakerMultiplier, and when two clauses both score +Infinity (for example linear FeatureField queries with weight 64 over feature values of 1e38) the result is Infinity + Infinity × 0 = NaN. explain() repeats the formula. The default search(q, n) uses DisjunctionMaxBulkScorer for a top-level tie-0 query since 10.1.0 and reports +Infinity, while exact-count (COMPLETE) searches, a dismax next to a selective FILTER clause and, with this trigger, explain() report NaN, a score TopScoreDocCollector documents as invalid; in a two-document index the +Infinity document loses the top spot to one scoring 1.0. It is in every release from 1.9 through 10.6.0 and on main. It needs at least two clauses that score +Infinity on the same document (every run got there by overflowing float), far beyond typical bounded scores, so it is Low priority; the fix is to return the maximum for tie 0, as getMaxScore already does.

1. The loop. DisjunctionMaxScorer.score (DisjunctionMaxScorer.java:59-73) keeps float scoreMax = 0 and double otherScoreSum = 0. A clause score >= scoreMax (:65) pushes the old maximum into otherScoreSum (:66) and takes its place (:67). With clause scores (+Inf, +Inf) the second one passes +Inf >= +Inf, so scoreMax and otherScoreSum are both +Infinity.
2. The fix site. :72 returns (float) (scoreMax + otherScoreSum * tieBreakerMultiplier). With tie 0, +Inf * 0 is NaN (IEEE 754) and +Inf + NaN is NaN. With one +Infinity clause, otherScoreSum stays finite and the result is +Infinity; with tie 0.1 it is Inf + Inf * 0.1 = +Infinity.
3. explain. DisjunctionMaxWeight.explain (DisjunctionMaxQuery.java:216-248) repeats the same steps in double and the same formula at :239, under the label "max of:" for tie 0 (:240-243).
4. Why the default search disagrees. getMaxScore already returns scoreMax for tie 0 (DisjunctionMaxScorer.java:99-100). For tie 0 under TOP_SCORES, with at least two clauses that have a scorer on the segment (with one, its scorer is used directly, DisjunctionMaxQuery.java:143-146), the weight returns a DisjunctionMaxBulkScorer (DisjunctionMaxQuery.java:162-169), which keeps Math.max of the clause scores starting from 0 (DisjunctionMaxBulkScorer.java:45, :71, :104). search(q, n) is TOP_SCORES because its total-hits threshold is 1000 (IndexSearcher.java:100, :599; TopScoreDocCollector.java:59); a threshold of Integer.MAX_VALUE is COMPLETE and goes through score(). Nesting depends on the plan: as a MUST clause next to a selective TermQuery FILTER the dismax scored NaN, next to a MatchAllDocsQuery FILTER +Infinity.

FeatureField stores 1e38 lossily, keeping the float's high bits (FeatureField.java:185-186, :240-251), so it comes back as 9.96921E37; 64 × 9.96921E37 is about 6.38e39, above Float.MAX_VALUE (3.4028235E38), so each clause scores +Infinity. For the repro's document: search(q, 10) +Infinity; COMPLETE search NaN; explain() NaN; as a MUST clause next to a FILTER on its id NaN. A document matching only one clause, and tie 0.1, give +Infinity on every path probed. With the FunctionScoreQuery trigger (double values of 1e39), explain() adds the finite doubles and reports +Infinity, while COMPLETE scoring is still NaN.

• Who. Applications that run a tie-0 DisjunctionMaxQuery (pure max; the constructor javadoc says a non-zero tie "should be small, on the order of 0.1") whose clauses can each reach +Infinity on the same document: FeatureField.newLinearQuery (Expert, weight up to 64) over feature values near 1e38 (run); a FunctionScoreQuery from the queries module over double doc values above Float.MAX_VALUE, for example 1e39 (run); or boosts near Float.MAX_VALUE, which BoostQuery accepts (read, not run).
• What shows. NaN in COMPLETE collection (exact total hit counts) and in a BooleanQuery with a selective FILTER clause; NaN in explain() with the FeatureField trigger but +Infinity with the FunctionScoreQuery trigger, whose explanations stay finite in double; +Infinity from the default search(q, n) (main and 10.6.0).
• Rank effects (run). On main, with doc 0 at +Infinity (a FunctionScoreQuery over 1e39 in both clauses) and doc 1 at 1.0, a COMPLETE top-1 search returns doc 1, and a top-2 search lists doc 0 with score NaN. On 9.12.3 the NaN document is missing from the COMPLETE hits and a bogus hit (doc 2147483647, score -Infinity) takes its place; 10.0.0 and 10.1.0 drop it from the top 10 (not bisected).
• Default vs opt-in. DisjunctionMaxQuery is core and no setting is involved, but every trigger is opt-in: an Expert function of an @lucene.experimental field, an optional-module query, or extreme boosts, at values that reach +Infinity (in every run, by overflowing float).
• Scale. One document is enough. No exception, no extra CPU or memory; the same with assertions on and off. Likelihood: contrived; no public report was found since 2006.

TestDisjunctionMaxTieZeroInfiniteScores (one method, extends LuceneTestCase, package org.apache.lucene.search of the lucene/core tests). One document; under two seconds. Seed DEADBEEF here; a run with seed 5EED fails the same way.

As a regression test the same method fits in TestDisjunctionMaxQuery; of the types it uses, that class lacks only org.apache.lucene.document.FeatureField. The file passes checkGoogleJavaFormat.

TestDisjunctionMaxTieZeroInfiniteScores > testTwoInfiniteDisjunctsScoreTheMax FAILED
    java.lang.AssertionError: expected:<Infinity> but was:<NaN>
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:5BBC1DA9FA2E1B3E]:0)
        at org.junit.Assert.fail(Assert.java:89)
        at org.junit.Assert.failNotEquals(Assert.java:835)
        at org.junit.Assert.assertEquals(Assert.java:577)
        at org.junit.Assert.assertEquals(Assert.java:701)
        at org.apache.lucene.search.TestDisjunctionMaxTieZeroInfiniteScores.testTwoInfiniteDisjunctsScoreTheMax(TestDisjunctionMaxTieZeroInfiniteScores.java:49)

# -Ptests.asserts=false: the same assertion fails the same way

• Contract. DisjunctionMaxQuery.java:30-32: it "scores each document with the maximum score for that document as produced by any subquery, plus a tie breaking increment for any additional matching subqueries"; DisjunctionMaxScorer.java:24-27 says the same. For tie 0 that is the maximum, and explain() labels it "max of:" (DisjunctionMaxQuery.java:241-242).
• Lucene's other paths follow the contract. getMaxScore (DisjunctionMaxScorer.java:99-100) and DisjunctionMaxBulkScorer (:71) give +Infinity for the same document. Upstream TestDisjunctionMaxQuery runs CheckHits.checkTopScores (:675, :682), which requires the COMPLETE and TOP_SCORES top hits to be equal (CheckHits.java:700-709); here even the top-1 hit differs.
• +Infinity is legal, NaN is not. TopScoreDocCollector.java:30-31 names only NaN and NEGATIVE_INFINITY as invalid scores. The test framework's AssertingScorer asserts !Float.isNaN(score) (AssertingScorer.java:129); a probe shows it accepts one +Infinity clause and trips "NaN score" on the tie-0 dismax.
• The inputs are legal. A feature value must be "a positive, finite, normal float" (FeatureField.java:130, checked at :153-172), and newLinearQuery accepts weights in (0, 64] (:590-597).
• History. In the history, CHANGES and MIGRATE entries, javadocs and tests reviewed, nothing asks for NaN here, and the discussions of the changes behind today's code (#9145, #14040) never mention NaN or infinity.

The strongest case for "intended": Lucene leaves overflow to the caller. BaseSimilarityTestCase says "we just limit the test to "reasonable" boost values but don't enforce this anywhere. too big, and you are asking for overflow" (BaseSimilarityTestCase.java:337-339); open #9064 proposes bounding boosts because they can give infinite scores; FeatureField is @lucene.experimental and its linear function "Expert"; and once two clauses are +Infinity, ranking among such documents is lost anyway.

Why it fails: all of that is about producing +Infinity, which Lucene treats as a legal score. The defect is the combinator turning two legal +Infinity scores into the invalid NaN while its own other paths, one +Infinity clause and tie 0.1 all give +Infinity, and the damage is not limited to infinite documents: the +Infinity document loses to one scoring 1.0. The executed cross-model review (OpenAI GPT-5.6) rated the intended-behaviour case weak, and the devil's-advocate verifier rejected it; this doc's own cross-model fact check rated it moderate (the formula is applied literally under IEEE arithmetic, the similarity tests aim at finite scores, and accepting an input is no promise of a finite score). Verdict: not intended, a Low defect. A maintainer may still call it too rare to matter; that is a fair outcome for a Low bug.

Options A and B were built and checked through gradle on 5adff78bb168; C was not run. A is recommended as the smallest change and the same shortcut getMaxScore already takes, but it is not fully semantics-preserving: it changes the sign of a -0.0 maximum and hides a NaN clause score that is not the maximum. Both are degenerate inputs (the test framework's AssertingScorer asserts that no score is NaN); if maintainers want the scorer to match DisjunctionMaxBulkScorer for every float input, B does that, and the cross-model fact check of this doc preferred B.

In DisjunctionMaxScorer.score, after the loop, return scoreMax when tieBreakerMultiplier == 0, as getMaxScore does (DisjunctionMaxScorer.java:99-100); in DisjunctionMaxWeight.explain (DisjunctionMaxQuery.java:239), use (float) max for tie 0. This is the hunt's fix, with the explain() line wrapped to 100 columns.

    if (tieBreakerMultiplier == 0) {
      return scoreMax; // the max, as getMaxScore and DisjunctionMaxBulkScorer compute it
    }
    return (float) (scoreMax + otherScoreSum * tieBreakerMultiplier);

        // DisjunctionMaxWeight.explain
        final float score =
            tieBreakerMultiplier == 0
                ? (float) max
                : (float) (max + otherSum * tieBreakerMultiplier);

Trade-offs

Smallest change. For finite clause scores the result is unchanged except for a -0.0 maximum ((float) (m + 0.0) is m for any other finite m). Two corner cases noted by the finder, the reproducer and the cross-model review: it returns -0.0f instead of +0.0f for a -0.0 maximum, and it hides a NaN clause score that is not the maximum (today that gives NaN). Option B avoids both.

What the checks validated

• Gradle in a scratch worktree at 5adff78bb168, seed DEADBEEF: the repro fails without the fix (assertions on and off) and passes with it (assertions off).
• With the fix and assertions on: the repro (1), TestDisjunctionMaxQuery (23), TestSimpleExplanations (70), TestComplexExplanations (12), TestSimpleSearchEquivalence (17) and TestBooleanQuery (30): 153 tests, 0 failures. checkGoogleJavaFormat passes.
• Earlier the hunt checked the same change by shadowing the classes: the repro passed, upstream TestDisjunctionMaxQuery passed 23 of 23, and the cross-model review's own tests passed 6 of 6.

In DisjunctionMaxScorer.score, for tie 0 return Math.max over the clause scores starting from 0, exactly as DisjunctionMaxBulkScorer does (:71); explain() as in A.

    if (tieBreakerMultiplier == 0) {
      // the max, as DisjunctionMaxBulkScorer computes it: the sum below would add Infinity * 0
      float max = 0;
      for (DisiWrapper w = topList; w != null; w = w.next) {
        max = Math.max(max, w.scorable.score());
      }
      return max;
    }

Trade-offs

The scorer then matches the bulk scorer for every input, including A's corner cases: a NaN clause score still gives NaN, and a -0.0 clause score gives +0.0 (Math.max(0f, -0.0f) is 0.0). Tie 0 skips the double sum, so no extra cost; five more lines than A.

What the checks validated

The same gradle runs as A: the repro passes (assertions off), and the same 153 tests pass with assertions on; checkGoogleJavaFormat passes.

return (float) (scoreMax + (tieBreakerMultiplier == 0 ? 0 : otherScoreSum * tieBreakerMultiplier));, the reproducer's variant.

Trade-offs

Keeps +0.0 for a -0.0 maximum, but hides a non-maximum NaN clause score like A.

Method: semi-formal (a proof-obligation audit of a class's contract, witnessed by an executable repro).

• The finder took the class javadoc (the maximum plus tie times the others) as the obligation for score(), getMaxScore() and explain(), and checked each against the code. getMaxScore discharges it with its tie-0 shortcut; score() and explain() fail it when two clause scores are +Infinity.
• The finder then wrote the public-API JUnit test, a probe of the execution paths (TOP_SCORES, COMPLETE, explain, nesting), and the tie-0 fix that makes the test pass.
• An independent reproducer, the refute-lens cross-model review and a devil's-advocate verifier reproduced it with their own tests; the finder-side cross-model review re-ran the finder's test and probe; and an adjudication re-ran the finder's and the reproducer's tests ("Prior reports, history and checks").