Flexible StandardQueryParser narrows out-of-range int literals with intValue(), so i:[2147483648 TO *] matches every document with the field

With a PointsConfig of type Integer, the flexible StandardQueryParser parses each point literal with the configured NumberFormat and converts it with Number.intValue() without checking that it fits in an int (PointRangeQueryNodeProcessor.java:109-111, PointQueryNodeProcessor.java:94-95 on main 645d4fe14a20). For 2147483648 the NumberFormat returns a Long, and intValue() keeps its low 32 bits: -2147483648. So i:[2147483648 TO *], which no int satisfies, parses to i:[-2147483648 TO 2147483647] and matches every document with the field, silently. i:4294967296 matches the document with 0, and i:[0 TO 3000000000] becomes i:[0 TO -1294967296] and returns none of the in-range documents. A literal beyond the long range saturates at the int limit instead, and in the forms tested Long fields saturate too, so there only a document at exactly the limit is wrong. The unchecked narrowing was written in 2011 (LUCENE-1768, first released in 3.4.0) and copied into the points processors in 2016 (LUCENE-7089, 6.0.0); every release up to 10.6.0 and main are affected. Rejecting a literal outside the type's range, as Lucene's XML query parser already does, fixes it; clamping the bound instead keeps the range semantics.

All lines are on main 645d4fe14a20, under lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/.

1. Pipeline. StandardQueryNodeProcessorPipeline.java:53-55 runs OpenRangeQueryNodeProcessor (turns * into an empty bound), then PointQueryNodeProcessor and PointRangeQueryNodeProcessor.
2. Parse. PointRangeQueryNodeProcessor.java:79-107 parses each non-empty bound with the configured NumberFormat (:82, :97); an unparseable literal throws QueryNodeParseException (:84-91, :99-106). For 2147483648 the integer DecimalFormat returns a Long; the JDK documents that it returns most integer values as a Long and a value that does not fit in a long as a Double (DecimalFormat.java:2202-2208).
3. Narrow, unchecked. For an Integer type, :109-111 do upperNumber = upperNumber.intValue(); lowerNumber = lowerNumber.intValue();. Long.intValue() keeps the low 32 bits: 2147483648 becomes -2147483648, 4294967296 becomes 0, 3000000000 becomes -1294967296. A literal beyond the long range is a Double, and Double.intValue() saturates: i:[99999999999999999999 TO *] becomes i:[2147483647 TO 2147483647] and matches a document at exactly Integer.MAX_VALUE.
4. Build. builders/PointRangeQueryNodeBuilder.java:63-79 casts to Integer, maps the empty upper bound to Integer.MAX_VALUE (:73-75) and calls IntPoint.newRangeQuery("i", -2147483648, 2147483647) (:79): the whole int range.
5. Single value. PointQueryNodeProcessor.java:83 parses and :94-95 narrow the same way; :115 builds [v TO v].
6. Long fields. PointRangeQueryNodeProcessor.java:112-114 and PointQueryNodeProcessor.java:96-97 call longValue(). Beyond the long range the NumberFormat returns a Double, and Double.longValue() saturates: l:[2^63 TO *] becomes [Long.MAX_VALUE TO Long.MAX_VALUE] and matches only a document at exactly that value. Executed with the integer format in four Long forms (three ranges and one single value); other formats were not tested.

Five documents with i = Integer.MIN_VALUE, -5, 0, 5, Integer.MAX_VALUE (and l at the long equivalents), main 645d4fe14a20, assertions on and off:

In-range literals, including the limits themselves (i:2147483647, i:"-2147483648", i:[-2147483648 TO 2147483647]), are correct.

• Who is hit. Callers of setPointsConfigMap with an Integer type (or, in the narrow saturating form, Long). The parser is opt-in, but the queryparser overview calls it "probably a good place to start" for new users (overview.html:38-40). Lucene's index browser Luke builds exactly this PointsConfig from its type map and parses the user's query string (SearchImpl.java:221-244). One downstream application, IPED, uses PointsConfig (its issue #510). The study found no PointsConfig use in Elasticsearch or Solr.
• What goes wrong. Silent wrong results in both directions: a bound past the near end of the int range fails open and matches every document with the field; a bound past the far end drops in-range documents (i:[0 TO 3000000000] returns 0 of 3); a single out-of-range value matches an unrelated value (i:4294967296 matches 0). Deterministic, with assertions on or off.
• What it takes. One document, one query string, the default codec. The literal must be outside the int range: realistic accidents are a value from another domain typed into an int field (a 13-digit millisecond timestamp, a 64-bit id, a phone number) or an upper bound picked "big enough".
• How likely: rare. Normal queries use values inside the field's domain.

TestPointRangeOutOfIntRange (53 lines with the license header, one test method, public API only). It fails at the count assertion on line 49; the message is the parsed query, which shows the wrap before any search runs, so the test framework's random codec and locale do not matter (the NumberFormat uses Locale.ROOT).

As a regression test this method, with the same configuration and query, can go into lucene/queryparser/src/test/org/apache/lucene/queryparser/flexible/standard/ unchanged if the fix keeps the range semantics. With the recommended fix (reject the literal) its count assertion becomes expectThrows(QueryNodeParseException.class, () -> parser.parse("i:[2147483648 TO *]", "i")), and the document, index and searcher are no longer needed (35 lines).

The same test fails on the 10.6.0, 10.5.2 and 9.12.3 release jars (standalone runner), and on 9.1.0, the oldest release whose test framework it compiles against.

cp $REPRO/TestPointRangeOutOfIntRange.java $LUCENE/lucene/queryparser/src/test/org/apache/lucene/queryparser/flexible/standard/
cd $LUCENE && ./gradlew :lucene:queryparser:test --tests org.apache.lucene.queryparser.flexible.standard.TestPointRangeOutOfIntRange -Ptests.seed=DEADBEEF

# gradle, main 645d4fe14a20, -Ptests.seed=DEADBEEF
TestPointRangeOutOfIntRange > testLowerBoundAboveIntMax FAILED
    java.lang.AssertionError: i:[-2147483648 TO 2147483647] expected:<0> but was:<1>
        at org.apache.lucene.queryparser.flexible.standard.TestPointRangeOutOfIntRange.testLowerBoundAboveIntMax(TestPointRangeOutOfIntRange.java:49)

# standalone runner, stock jars, seed DEADBEEF
main 645d4fe14a20  -ea / -da   tests_run=1 failures=1   same message
10.6.0             -ea / -da   tests_run=1 failures=1   same message
10.5.2             -ea / -da   tests_run=1 failures=1   same message
9.12.3             -da         tests_run=1 failures=1   same message

• Contract. StandardQueryParser.java:145-158: "inclusive range; selects documents whose name field has any value between Jones and Smith, including boundaries" and "one-sided range; selects documents whose score field is larger than 2.5". PointsConfig.java:39, :57: the type is "the numeric type used to index the numeric values", with no precondition on literals. No javadoc, package doc, CHANGES or MIGRATE entry mentions narrowing or out-of-range literals. Equally, nothing says what should happen to a literal the type cannot represent: the javadoc rules out the observed result but does not choose between an error and clamping.
• The same code rejects a literal it cannot parse. A literal from which the configured NumberFormat cannot read a number throws QueryNodeParseException(COULD_NOT_PARSE_NUMBER) (PointRangeQueryNodeProcessor.java:84-91, :99-106; PointQueryNodeProcessor.java:85-92); an empty one throws NUMERIC_CANNOT_BE_EMPTY (PointQueryNodeProcessor.java:104-108). Otherwise the processors are as lenient as the format: NumberFormat.parse(String) throws only when no number can be read at the start of the text, and the integer format stops at a decimal point, so i:12abc parses to i:[12 TO 12], i:1.5 to i:[1 TO 1] and i:[1.5 TO 3.9] to i:[1 TO 3] (executed on main). A maintainer may see the narrowing as part of that leniency.
• The sibling XML query parser rejects this bound. xml/builders/PointRangeQueryBuilder.java:69-70: "A ParserException will be thrown if an error occurs parsing the supplied lowerTerm or upperTerm into the numeric type specified by type"; it uses Integer.parseInt (:86-87). On main, <PointRangeQuery fieldName="i" type="int" lowerTerm="2147483648"/> throws "Could not parse lowerTerm or upperTerm into a number".
• Tests. Upstream TestPointQueryParser.java:33-84 uses only 1, 3, 1.5 and 3.6, with exactly the repro's configuration. No queryparser test uses 2147483648, 4294967296, MAX_VALUE or "overflow" with a PointsConfig.
• History. The unchecked intValue()/longValue() came with LUCENE-1768 (#2842, 2011) for the legacy numeric processors and was copied by LUCENE-7089 (#8145, 2016), which added points "the exact same way legacy numerics works". Neither discussion mentions out-of-range literals, overflow or intValue.

The strongest case for "not a bug": the literal lies outside the field's int domain, so Integer.class implicitly limits the input and the result is unspecified, a validation gap rather than a contract violation. A verifier of the sibling bug LFV-050 read it this way first, and the reviewer from another model family rated the argument moderate. Add to it that the processors inherit the format's general leniency (above), and that PointsConfig takes any caller-supplied NumberFormat, so an application can plug in a stricter one; the 2011 design discussion already left conversions to a caller-supplied NumberFormat (#2842).

Why it still fails: the parser accepts the literal without error and returns a query that matches values the query text excludes; the same processors reject a literal they cannot parse, and the XML parser rejects this one; with the stock configuration (upstream's test, Luke) an application can only avoid it by validating literals itself or writing a stricter NumberFormat; and the under-match form is a meaningful int query: i:[0 TO 3000000000] contains the documents 0, 5 and Integer.MAX_VALUE and returns none of them.

Two fixes were validated with gradle in a scratch worktree at 645d4fe14a20 (JDK 25, -Ptests.seed=DEADBEEF); the third option is the candidate step's causal check.

PointRangeQueryNodeProcessor.java checks both parsed bounds before :109; PointQueryNodeProcessor.java calls the same helper before :94., +34 lines, two files (with one code comment reworded after the fact check).

static void checkFitsType(Number number, Class<? extends Number> type, String text)
    throws QueryNodeParseException {
  final double value = number.doubleValue();
  final boolean fits;
  if (Integer.class.equals(type)) {
    fits = value >= Integer.MIN_VALUE && value <= Integer.MAX_VALUE;
  } else if (Long.class.equals(type)) {
    // a DecimalFormat returns a value that does not fit in a long as a Double
    fits = (number instanceof Double == false && number instanceof Float == false)
        || (value > -0x1p63 && value < 0x1p63);
  } else {
    fits = true;
  }
  if (fits == false) {
    throw new QueryNodeParseException(
        new MessageImpl(QueryParserMessages.COULD_NOT_PARSE_NUMBER, text, type.getName()));
  }
}

Trade-offs

• Smallest change; in-range literals, including the limits, are unchanged; matches the XML query parser and the processors' own error for unparseable numbers; independent of LFV-050.
• A range with one bound past the far end, such as i:[0 TO 3000000000], now fails to parse instead of returning the in-range documents. Applications that send such queries get an error instead of a wrong answer.
• The check covers what a DecimalFormat returns (the configuration of upstream's test and of Luke): on Integer fields it compares doubleValue() with the int limits, which decides correctly for any integral value; on Long fields it range-checks only Double and Float results, so a custom NumberFormat that returns a BigDecimal or BigInteger beyond the long range is not caught. It is not a general literal validation: the format's own leniency (trailing text, a dropped fraction) stays. Reusing COULD_NOT_PARSE_NUMBER with the type name is a choice; a dedicated "out of range" message may read better.

What the checks validated

• Gradle: :lucene:queryparser:checkGoogleJavaFormat passes; the whole :lucene:queryparser:test suite passes, 534 tests in 31 suites, 1 skipped, 0 failures, with the regression test (the minimal test with expectThrows) and TestPointQueryParser (4 tests).
• An independent verifier's five-test literal matrix (its oracle accepts a clean parse error): 5 of 5 pass; every in-range control is unchanged and every out-of-range row is rejected, for example Could not parse text "2147483648" using java.lang.Integer.
• The unchanged minimal test then fails with that exception, by design, hence the expectThrows form of the regression test.
• Re-run with an unpublished file on a fresh scratch worktree of 645d4fe14a20: checkGoogleJavaFormat and the whole :lucene:queryparser:test suite pass, 534 tests in 31 suites, 1 skipped, 0 failures; the unchanged minimal test fails with the rejection.

In the processors, a bound beyond the type's range is clamped to the limit, and the limit is excluded when no value of the type can satisfy the bound: i:[2147483648 TO *] becomes i:{2147483647 TO *], i:[0 TO 3000000000] becomes i:[0 TO 2147483647]. The builder must then turn an exclusive bound at the limit into MatchNoDocsQuery, which is the fix of the sibling bug LFV-050 (it also makes an open bound inclusive). +54/-4 in the processors, +13 in the builder.

Trade-offs

• Correct answers instead of an error, the unchanged minimal test is the regression test, and it fixes LFV-050 as well.
• Larger, couples the two bugs, and changes the parsed query of every out-of-range literal. Without the builder part it does not work: the builder's lower + 1 wraps Integer.MAX_VALUE and the minimal test still fails with the same message.

What the checks validated

• Gradle, same worktree: the unchanged minimal test passes; the literal matrix gives the exact count on every row (i:[2147483648 TO *] and i:4294967296 build MatchNoDocsQuery; i:[0 TO 3000000000] builds i:[0 TO 2147483647], 3 hits); checkGoogleJavaFormat and the whole :lucene:queryparser:test suite pass, 534 tests, 0 failures. The processor part alone: the minimal test still fails.

Replace intValue() with a clamp to [Integer.MIN_VALUE, Integer.MAX_VALUE].

Trade-offs

Incomplete: i:[2147483648 TO *] becomes i:[2147483647 TO 2147483647] and matches a document at exactly Integer.MAX_VALUE, the gap the Long sites already have; the one-document repro passes only because its value is 0. The single-value processor is not covered either.

Method: non-formal. The 2026-10-22 study verified LFV-050, a finding of its BKD and points proof experiment, on main 7cecf79523. While reading PointRangeQueryNodeProcessor, its verifier noted that the parsed Number is narrowed with intValue() without a range check, and called it "a validation gap rather than a clean contract violation".

• Study follow-up 4 executed it with its own four-literal test, found all four wrong, and showed that LFV-050's fixes do not change it: a separate root cause.
• The hunt's candidate step reduced it to the one-method test and ran it on main and three releases; a review by another model family could not run code; a tie-break wrote its own literal matrix and main() probe, confirmed the root cause at both processor sites, and found the under-match form; a history sweep ran 136 releases.