DoubleValuesSource rounds the skip-index bound to the nearest float, so a boosted FunctionScoreQuery reports a max score one float step below a real score and top-k search can return the wrong top hit

Since #16431 (unreleased, 11.0.0) the field sources of DoubleValuesSource (fromLongField, fromIntField, fromDoubleField, fromField with a declared monotonicity) report per-block bounds from the doc-values skip index, and FunctionScoreQuery turns them into a block-max score for top-k pruning. The value bound is (float) decoder.applyAsDouble(skipper.maxValue(level)): a nearest-float cast, which for a value that is not a float can land below the block's largest value (16,777,217 becomes 16,777,216). FunctionScoreQuery then multiplies that rounded value by the boost in float, while it scores each document as (float) (value * boost) from the exact value. With boost 1.5 a document scores 25,165,826 under a block bound of 25,165,824, one float step lower. MaxScoreBulkScorer (and BlockMaxConjunctionBulkScorer) trust the bound, so once the k-th collected hit scores 25,165,824 the block is skipped and the better document is lost. With the default codec and plain IndexSearcher.search(q, 1), a 5,000-document index returns the wrong top hit; boost 1, float-exact values and fromFloatField are not affected. Only main and branch_11x have it; every release returns the right hit. Rounding the float bound outward in DoubleValuesSource fixes it.

1. The value bound rounds to nearest. DoubleValuesSource.java:571-584 (getMaxScore of the field source): with a skip index and a declared monotonicity it picks the first skipper level that covers upTo and returns (float) decoder.applyAsDouble(rawBound) (:580), where rawBound is the level's maxValue (INCREASING) or minValue (DECREASING) (:576-579). getMinScore (:586-599) does the same at :595. A Java narrowing cast rounds to nearest, so the max bound can be below the largest value and the min bound above the smallest (2^24 + 3 becomes 16,777,220).
2. Which sources. fromLongField is fromField(field, v -> (double) v, INCREASING), fromIntField returns fromLongField, fromDoubleField decodes raw bits, fromFloatField decodes a float (DoubleValuesSource.java:329-347). Longs above 2^24 in magnitude and doubles that are not floats can round the wrong way; fromFloatField values are floats and cannot.
3. The score rounds once, the bound twice. FunctionScoreQuery.java:243-252: score() returns (float) (factor * boost) from the exact double (:247). :262-269: getMaxScore returns innerMaxScore * valueMaxScore * boost in float (:268) from the already-rounded value bound. With a constant-score inner query (bound 1) and boost 1 the bound stays sound because the cast is monotone; with any other boost it can end one float below the score.
4. Pruning trusts it. IndexSearcher.search(q, n) collects with TopScoreDocCollectorManager(n, after, 1000) (IndexSearcher.java:100, :599), i.e. TOP_SCORES (TopScoreDocCollector.java:58-60); once more than 1,000 hits have been counted (:155) it sets the minimum competitive score to Math.nextUp of the k-th score (:154-160). MaxScoreBulkScorer.partitionScorers() adds the clause bounds of a window and skips the window when the sum is below that minimum (MaxScoreBulkScorer.java:474-517, :502; skip at :133-138).
5. Only near-ties are lost. The bound is about one float step low, so a document is dropped only when an already-collected hit scores within about one float step below it.

One document (the minimal repro): count = 16,777,217, boost 1.5. (float) 16777217.0 = 16,777,216; 16777216f * 1.5f = 25,165,824 (exact); (float) (16777217.0 * 1.5) = (float) 25165825.5 = 25,165,826. The scorer reports getMaxScore 25,165,824 and score() 25,165,826.

5,000 documents in one segment (the finder's test): doc 0 = 2^24 (score 25,165,824), doc 4999 = 2^24 + 1 (score 25,165,826), only doc 1 matches body:b, query SHOULD boosted function query + SHOULD body:b. The skip interval of docs 4096-4999 reports the value bound 16,777,216 and the score bound 25,165,824, and the text clause has no document there (window bound 0, MaxScoreBulkScorer.java:431-445); with doc 0 on top the searcher needs 25,165,826, so that window is skipped and the search returns doc 0. The same with plain search(q, 1), and with MUST function query + MUST text clause (BlockMaxConjunctionBulkScorer).

Ordinary doubles (fromDoubleField, boost 1.1): 0.065 scores 0.0715 under a bound of 0.071499996; with doc 4999 = 1000.0007, plain search(q, 1) returns doc 0 (1100.0007) instead of doc 4999 (1100.0009).

• Who. Users of main or branch_11x who rank with FunctionScoreQuery over fromLongField, fromIntField, fromDoubleField or a fromField with a declared monotonicity, on a numeric field with the opt-in doc-values skip index (NumericDocValuesField.indexedField, or a field type with DocValuesSkipIndexType.RANGE), with a boost other than 1 (a BoostQuery or a boosted clause), as one scoring clause next to another: executed for SHOULD + SHOULD and for MUST + MUST with a text clause.
• Trigger. A skip block whose largest value is not exactly a float: a long above 2^24 (16,777,216) in magnitude that a float cannot hold (every odd one, for example; 2^24 + 2 is a float), or an ordinary double such as 0.065 or 1000.0007. For such fields the low bound is common; a hit is lost only when it beats an already-collected hit by about one float step. Deterministic for a fixed index and query.
• Effect. Silent wrong results: the true top hit (or a top-k member) is replaced by a slightly worse one, and Scorer#getMaxScore and DoubleValues#getMaxScore report bounds below real scores and values. No exception, default codec and searcher, assertions on and off. Never a superset: returned hits still match the query and all its filters.
• Not affected. Boost 1, values that are exact floats, fromFloatField, fields without a skip index, boostByValue and boostByQuery (their bound is +∞), and every release.
• How likely: rare. The one-float-step near-tie is the limit: the finder's randomized TOP_SCORES-versus-exhaustive comparison (202,320 top-k queries with the bug present) never hit one by chance; the repros construct it on purpose.

ByteBuffersDirectory and a plain IndexSearcher. The codec is the test framework's random choice (Asserting(Lucene104) with seed DEADBEEF); the doc-values formats it can pick all implement the skip index, and with one document the block's largest value is that document's value, so the outcome does not depend on the seed.

The test shows the broken bound on one document. The wrong top hit described above needs a second scoring clause and two skip intervals (5,000 documents); it is the same bug and is not part of this repro.

Regression test: this same test; it passes with the recommended fix.

cp $REPRO/TestFunctionScoreQueryMaxScoreRounding.java $LUCENE/lucene/queries/src/test/org/apache/lucene/queries/function/
cd $LUCENE && ./gradlew :lucene:queries:test --tests TestFunctionScoreQueryMaxScoreRounding -Ptests.seed=DEADBEEF -Ptests.asserts=true
# assertions off fails the same way: -Ptests.asserts=false

# gradle, stock 645d4fe14a20, -Ptests.seed=DEADBEEF -Ptests.asserts=true (stack trimmed; -Ptests.asserts=false identical)
> Task :lucene:queries:test FAILED

TestFunctionScoreQueryMaxScoreRounding > testBoostedLongScoreWithinMaxScore FAILED
    java.lang.AssertionError: score 2.5165826E7 > getMaxScore 2.5165824E7
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:BDFF435CEEBB315A]:0)
        at junit@4.13.2/org.junit.Assert.fail(Assert.java:89)
        at junit@4.13.2/org.junit.Assert.assertTrue(Assert.java:42)
        at org.apache.lucene.queries.function.TestFunctionScoreQueryMaxScoreRounding.testBoostedLongScoreWithinMaxScore(TestFunctionScoreQueryMaxScoreRounding.java:59)
  2> NOTE: test environment is: codec=Asserting(Lucene104): {}, ...
1 test completed, 1 failed

# the finder's 5,000-document class on the same stock build (gradle, seed DEADBEEF, -ea and -da): 3 tests, 3 failed
testTopHitWithDynamicPruning  java.lang.AssertionError: TOP_SCORES top hit (score 2.5165824E7) differs from COMPLETE expected:<4999> but was:<0>
testMaxScoreIsUpperBound      java.lang.AssertionError: doc 4999 scores 2.5165826E7 > getMaxScore(4999) = 2.5165824E7
testValueBound                java.lang.AssertionError: value 1.6777217E7 > getMaxScore(4999) = 1.6777216E7

• The contracts. DoubleValues#getMaxScore returns "the maximum score that documents between the current position and upTo can produce" (DoubleValues.java:55-58); Scorer#getMaxScore is the maximum score of the documents up to upTo (Scorer.java:75-79); Scorable#setMinCompetitiveScore lets a scorer "safely ignore all documents whose score is less than the given minScore" (Scorable.java:45-51). Here a document whose score equals the minimum (25,165,826) is ignored.
• Upstream tests. TestDoubleValuesSource.java:412-422 (testMaxScoreBeyondTheCurrentBlock, from #16697) asserts getMinScore(upTo) <= doubleValue() <= getMaxScore(upTo), the exact double against the float bound, over the values 0-199 (:384-397), all exact floats. TestFunctionScoreQuery has no skip-indexed field at all, so its bound tests take the +∞ branch. The test framework asserts score <= maxScore (CheckHits.java:766, AssertingScorer.java:130) and equal TOP_SCORES and COMPLETE top hits (CheckHits.checkTopScores, :690-697).
• Lucene rounds bounds outward elsewhere. The collector reasons at one-float precision ("we can require the next float", TopScoreDocCollector.java:154-160); MathUtil.sumUpperBound pads summed bounds for floating-point error (MathUtil.java:177-194).
• History. #16431's description shows the cast, (float) decoder.applyAsDouble(skipper.maxValue(0)); its review (19 comments, 14 inline comments, 15 reviews) discussed monotonicity only, and the author (rajat315315), explaining why a decreasing function takes the skipper's minimum, wrote that this gives "exact and sound block upper bounds" (PR comment, 2026-07-29). #16697 fixed two other defects of the same methods and kept the cast.
• Precedent. #13397 (jpountz, merged 2024-05-21, closes #13371 and #13396): "It sums up max scores in a float when it should sum them up in a double like we do for Scorer#score(). Otherwise, max scores may be returned that are less than actual scores."

The strongest case: scores are floats, so the nearest float is the tightest cheap bound, and a one-ulp near-tie is noise. A weaker one: upstream's own customSqrt test source also casts to nearest (TestFunctionScoreQuery.java:538).

Why it fails: the bound is then below the score Lucene itself returns for that document, so the pruned search of a query returns a different top hit than the exhaustive search of the same query, which the TOP_SCORES contract and the test framework do not allow; the collector's own tie-break works at exactly that precision (Math.nextUp). The customSqrt source is test code with a loose assert (maxScore >= 22.3f, :586); it shows the rounding direction was not considered, not that it was chosen. Attribution caveat: the defect can equally be placed in FunctionScoreQuery's float product; the suggested fix covers both levels.

Option A was built and run through gradle. B (round up in FunctionScoreQuery) and C (double-valued bounds) were not run; B must round up unconditionally, because the value already arrives rounded down and 16,777,216 × 1.5 is exact.

In the field source's getMaxScore and getMinScore (DoubleValuesSource.java:580, :595), keep the decoded double and round the float bound away from it only when the cast moved the wrong way (+8/-2 lines).

// getMaxScore
double bound = decoder.applyAsDouble(rawBound);
float floatBound = (float) bound;
// round up: the float bound must not be below the double values it bounds
return floatBound < bound ? Math.nextUp(floatBound) : floatBound;

// getMinScore
double bound = decoder.applyAsDouble(rawBound);
float floatBound = (float) bound;
// round down: the float bound must not be above the double values it bounds
return floatBound > bound ? Math.nextDown(floatBound) : floatBound;

Trade-offs

• Fixes both levels. DoubleValues bounds then cover the double values, as TestDoubleValuesSource expects. For FunctionScoreQuery with a constant-score inner query: the rounded-up value bound and the boost are floats, their product is exact in double and rounding is monotone, so the float product covers (float) (v * boost) for every value below the bound (the finder's reasoning; the finder's 5e7-pair JVM check found 0 violations with the fix and 1,975,394 without, not re-checked by a verifier).
• Cost. Unchanged for values that are floats (longs up to 2^24 in magnitude, float-valued doubles); otherwise one float looser (for the repro value 16,777,218, and the function bound 25,165,828). No benchmark was run.
• NaN. Both comparisons are false for NaN, so a NaN bound passes through unchanged (the separate LFV-189).
• Scope. It does not change FunctionScoreQuery; the other bound defects of the same feature (LFV-189, LFV-203, LFV-211, LFV-214) need their own changes.

What the checks validated

Applied to a scratch worktree of 645d4fe14a20 and run through gradle with OpenJDK 25.0.3, seed DEADBEEF (2026-10-31):

• stock: the minimal test fails with assertions on and off; the finder's 5,000-document class fails 3 of 3 with assertions on and off;
• with the fix: the minimal test passes with assertions on and off; the finder's class passes 3 of 3;
• core TestDoubleValuesSource, TestDoubleValuesSourceRescorer, TestLongValuesSource, TestSortRescorer and TestMaxScoreBulkScorer pass (38 tests, 0 failures); queries TestFunctionScoreQuery, TestFunctionScoreExplanations, TestFunctionQuerySort, TestFunctionMatchQuery and TestValueSources pass (67 tests, 0 failures);
• the whole :lucene:queries:test (512 tests, 0 failures, 5 skipped) and :lucene:expressions:test (170 tests, 0 failures) pass; checkGoogleJavaFormat, ecjLintMain and forbiddenApisMain for core pass.
• Earlier: the same change makes every verifier's and reviewer's own test pass, and with all five fixes of this hunt combined upstream TestFunctionScoreQuery (17) and TestDoubleValuesSource (11) pass.

At FunctionScoreQuery.java:268, return Math.nextUp(innerMaxScore * valueMaxScore * boost).

Trade-offs

It must round up unconditionally: the value bound already arrives rounded down, and 16,777,216 × 1.5 = 25,165,824 is exact, so rounding up only an inexact product changes nothing for the repro (arithmetic executed). Whether one extra step always covers the two roundings (value, then product) against the score's one was not checked, and DoubleValues#getMaxScore stays below the value for any other consumer.

Return the bounds as doubles from DoubleValues and round once, upward, in FunctionScoreQuery.

Trade-offs

Numerically cleanest, but it changes the signature of DoubleValues#getMaxScore/getMinScore, which #16431 added; that is still possible before 11.0.0 ships.

Method: semi-formal (the hunt's tier for a hypothesis formed while modelling and then witnessed by a solver). The hunt unit covered function queries and block-max pruning.

• Model. The score and the block bound of FunctionScoreQuery over the field source were written in IEEE-754 SMT (QF_FP), with a model-to-Java line map. Z3 4.12.2 and cvc5 1.4.2: score above bound with a constant-score inner query and a boost other than 1 is SAT (one query for doubles, one for longs); with boost 1 it is UNSAT; the float cast is monotone (UNSAT). The registration check re-ran these queries with both solvers and replayed the fresh models as Java arithmetic: all violate score <= bound.
• JUnit. The models were replayed on the JVM, generalised (long 2^24 + 1, doubles such as 0.065 with boost 1.1) and turned into a directed public-API test (5,000 documents) that fails on main with assertions on and off; the minimal repro above is that test cut down to one document and one assertion.