Flexible StandardQueryParser: an exclusive int/long point bound at MAX/MIN wraps around, so the query matches every document with the field instead of none

With the flexible StandardQueryParser and a PointsConfig of type Integer or Long, an exclusive bound ({, }, >, <) exactly at the type's MAX or MIN wraps around. PointRangeQueryNodeBuilder makes the bound inclusive with a plain lower + 1 / upper - 1, so i:{2147483647 TO *] is built as i:[-2147483648 TO 2147483647] and matches every document with the field, where the documented meaning ("larger than" Integer.MAX_VALUE) matches none. It is silent, deterministic and independent of the index, and it has shipped in every release since 6.0.0, when this builder replaced the overflow-safe legacy numeric path.

1. The syntax parser records {/} and >/< as exclusive flags: > sets lowerInclusive = false and the upper bound to * (StandardSyntaxParser.jj:763-768; < at :751-756).
2. OpenRangeQueryNodeProcessor, which runs first (StandardQueryNodeProcessorPipeline.java:53-55), turns an unescaped * into empty text (:44-54). PointRangeQueryNodeProcessor parses only non-empty text (:77-79, :94), so an open bound stays null, and converts the parsed numbers to Integer (:109-111) or Long (:112-114).
3. PointRangeQueryNodeBuilder.build, Integer branch (:63-79): an open lower bound becomes Integer.MIN_VALUE (:65-67) and an open upper bound MAX_VALUE (:72-75); then if (minInclusive == false) { lower = lower + 1; } (:68-70) and if (maxInclusive == false) { upper = upper - 1; } (:76-78), with no overflow check; then IntPoint.newRangeQuery(field, lower, upper) (:79), whose bounds are inclusive. The Long branch repeats it (:85-87, :93-95, :96).
4. For i:{2147483647 TO *] the lower step gives -2147483648 and the open upper bound 2147483647: the full range. For [* TO MIN} the upper step wraps to MAX. For {MAX TO MAX] the lower step wraps and the upper stays MAX.

The method's only comment is :62, "TODO: push down cleaning up of crazy nulls and inclusive/exclusive elsewhere"; nothing mentions overflow. Float and Double use Math.nextUp/nextDown (:97-130) and do not wrap.

Five documents with i and l = MIN, -1, 0, 1, MAX. Each of i:{2147483647 TO *], i>2147483647, i:[* TO -2147483648}, i<"-2147483648", i:{2147483647 TO 2147483647], l:{9223372036854775807 TO *], l>9223372036854775807, l:[* TO -9223372036854775808} and l<"-9223372036854775808" builds the full range and matches 5 of 5, where 0 are expected. All 10 controls at and next to the limit are exact (7 strict bounds one step inside the limit, the inclusive i:[2147483647 TO *] and i>=2147483647, and i:{0 TO 2147483647]); for example i:{2147483646 TO *] gives 1 hit and l>9223372036854775806 gives 1. i:{2147483647 TO 2147483647} builds i:[-2147483648 TO 2147483646] and matches 4 of 5.

• Who. setPointsConfigMap with an Integer or Long type. Opt-in, but it is the path a maintainer recommends for numeric fields (Uwe Schindler on java-user, 2023-11-14, "StandardQueryParser and numeric fields") and the one Luke uses when a user assigns a point type to a field (SearchImpl.java:221-240). The recorded GitHub code search found no indexed PointsConfig use in elastic/elasticsearch or apache/solr.
• Trigger. An exclusive bound or >/< exactly at the type's MAX or MIN. People rarely type it; the plausible route is generated query text on a field that uses MAX/MIN as a sentinel ("never expires" stored as Long.MAX_VALUE, or a "values after the last one seen" filter field:{<last> TO *] when the last value is MAX). That route is an inference; no user report was found.
• Effect. Silent wrong results that fail open: a filter meant to match nothing matches every document with the field; negated, it hides everything. Deterministic, one document shows it, same with assertions on and off.

Oracle: the documented meaning of {x TO *], "larger than" x, with x = Integer.MAX_VALUE. LuceneTestCase is only the base class; the result does not depend on the seed (DEADBEEF and 5EED1234 give the same failure). To see the wrapped query in the message, keep the parsed query in a local and pass query.toString() to assertEquals; it then reads i:[-2147483648 TO 2147483647] expected:<0> but was:<1>.

Regression test: this same class (or its one method added to TestPointQueryParser); it passes with the recommended fix. If maintainers choose to reject such a bound instead, assert the exception.

cp $REPRO/TestExclusivePointBoundAtMaxValue.java $LUCENE/lucene/queryparser/src/test/org/apache/lucene/queryparser/flexible/standard/
cd $LUCENE && ./gradlew :lucene:queryparser:test --tests TestExclusivePointBoundAtMaxValue -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)
   >     java.lang.AssertionError: expected:<0> but was:<1>
   >         at __randomizedtesting.SeedInfo.seed([DEADBEEF:A3F4C59FD775AE79]:0)
   >         at org.apache.lucene.queryparser.flexible.standard.TestExclusivePointBoundAtMaxValue.testNothingIsGreaterThanMaxValue(TestExclusivePointBoundAtMaxValue.java:47)

:lucene:queryparser:test (FAILURE): 1 test, 1  failure

# the nine limit forms on stock main (5 docs, i and l = MIN, -1, 0, 1, MAX; independent test)
i:{2147483647 TO *]           -> i:[-2147483648 TO 2147483647]                    hits=5 expected=0
i>2147483647                  -> i:[-2147483648 TO 2147483647]                    hits=5 expected=0
i:[* TO -2147483648}          -> i:[-2147483648 TO 2147483647]                    hits=5 expected=0
i<"-2147483648"               -> i:[-2147483648 TO 2147483647]                    hits=5 expected=0
i:{2147483647 TO 2147483647]  -> i:[-2147483648 TO 2147483647]                    hits=5 expected=0
l:{9223372036854775807 TO *]  -> l:[-9223372036854775808 TO 9223372036854775807]  hits=5 expected=0
l>9223372036854775807         -> l:[-9223372036854775808 TO 9223372036854775807]  hits=5 expected=0
l:[* TO -9223372036854775808} -> l:[-9223372036854775808 TO 9223372036854775807]  hits=5 expected=0
l<"-9223372036854775808"      -> l:[-9223372036854775808 TO 9223372036854775807]  hits=5 expected=0
controls at and next to the limit (e.g. i:{2147483646 TO *] 1 hit, i:[2147483647 TO *] 1 hit, l>9223372036854775806 1 hit): 10 of 10 exact

• Documented semantics. StandardQueryParser.java:154-158: score:{2.5 TO 7.3} is an "exclusive range ... excluding boundaries", and score:{2.5 TO *] "selects documents whose score field is larger than 2.5". PointsConfig documents no restriction on bound values, and 2147483647 is a valid int literal.
• The API the builder calls says how. IntPoint.java:186-187, LongPoint.java:205-206: "Ranges are inclusive. For exclusive ranges, pass Math.addExact(lowerValue, 1) or Math.addExact(upperValue, -1)." When the builder was written the javadoc said "pass lowerValue + 1 or upperValue - 1" (IntPoint.java at 89cc676f2bf, line 177); eight days later c1e95d7b4da (Adrien Grand, 2016-03-17) replaced exactly that advice with Math.addExact, in the same release (6.0.0). The builder still uses the plain + 1.
• Regression against the replaced code. LUCENE-7089 (#8145) added points "the exact same way legacy numerics works", but the legacy query guarded the step (if (minBound == Long.MAX_VALUE) break;, LegacyNumericRangeQuery.java at 89cc676f2bf, lines 416-419 and 456-459). On 6.0.0 the legacy path gives 0 hits for the same query, the points path 1.
• Precedent. LUCENE-7111 (#8166, 751a53fe00a, 2016, CHANGES "Bug Fixes"): DocValuesRangeQuery.newLongRange "behaves incorrectly for Long.MAX_VALUE and Long.MIN_VALUE", the same wrap; Robert Muir suggested Math.addExact/subtractExact there.
• Tests. No upstream test asserts the wrap: TestPointQueryParser.java:33-55 checks only [1 TO 3] and exact values; TestQPHelper.java:667 asserts that field>a means {a TO *].

The strongest case for "intended": the package docs call the standard package "an example Lucene query parser implementation"; LUCENE-7092 (#8148) kept point ranges inclusive-only because callers "just add/subtract 1"; {MAX TO *] asks for values outside the type; and a maintainer might prefer an exception to an empty query (the read-only OpenAI GPT-5.6 review's argument).

Why it fails: the same package docs call StandardQueryParser "the default implementation of a fully fledged query parser"; LUCENE-7092 says nothing about MAX/MIN, and eight days after the builder landed the javadoc's plain + 1 advice was replaced with an overflow-checked step; the literal is inside the configured type and "larger than MAX" gives an empty match set; and exception versus empty result is a real choice of fix that maintainers may weigh either way, while matching the whole domain is wrong under both. Upstream has fixed StandardQueryParser defects as bugs before (LUCENE-6249, LUCENE-5344).

Two fixes were validated with gradle in a scratch worktree of 645d4fe14a20; a third is described. All three make i:{2147483647 TO *] match nothing or fail loudly; they differ in what else they change.

+13 lines in PointRangeQueryNodeBuilder.java: an import and four guards, one before each + 1 / - 1 in the Integer and Long branches.

if (minInclusive == false) {
  if (lower == Integer.MAX_VALUE) {
    return new MatchNoDocsQuery("exclusive lower bound is Integer.MAX_VALUE");
  }
  lower = lower + 1;
}
// ... and before upper = upper - 1:
if (upper == Integer.MIN_VALUE) {
  return new MatchNoDocsQuery("exclusive upper bound is Integer.MIN_VALUE");
}
// the same two guards in the Long branch with Long.MAX_VALUE / Long.MIN_VALUE

Trade-offs

• Changes results only for bounds exactly at MAX/MIN, which are wrong today; an empty result is the match set the documented semantics give and what the legacy path returned.
• Leaves the open-bound sibling (i:{* TO 0] drops a MIN_VALUE document) unchanged.
• Backport-friendly: the file is the same blob on 9.12.3, 10.5.2, 10.6.0 and main.
• A downstream project with its own builder keyed by PointsConfig made the same choice (FoundationDB/fdb-record-layer#1849, 2022).

What the checks validated

• Gradle, scratch worktree of 645d4fe14a20: the repro passes with -Ptests.asserts=true and =false; the tie-break's independent test (9 limit forms, 10 controls) passes 2 of 2.
• :lucene:queryparser:test, whole module, seeds DEADBEEF and CAFEBABE: SUCCESS, 536 tests (533 + the repro + 2 independent), 1 skipped, 0 failed.
• checkGoogleJavaFormat, forbiddenApisMain/Test and ecjLintMain/Test pass (run without the copied-in independent test, whose own formatting fails the check; it is not part of the fix). An independent fact check repeated the repro, the module (534 tests with the repro) and the three lint checks with this diff.

Also sets minInclusive = true / maxInclusive = true when a bound is null, in all four type branches (+13 lines).

Trade-offs

Also fixes i:{* TO 0] dropping the MIN_VALUE document and float/double {* TO x] dropping -Infinity. But it changes behaviour the study verifier called debatable: the legacy numeric query and TermRangeQuery ignore exclusivity on an open bound, and Uwe Schindler (LUCENE-3338, #4411, 2011) was "glad" that [x TO *] does not behave differently from [x TO *}. Better as a separate decision.

What the checks validated

Same gradle runs: the repro passes with assertions on and off, the independent test 2 of 2, the whole module with both seeds 536 tests and 0 failures, checkGoogleJavaFormat passes (without the copied-in independent test).

Follow the IntPoint/LongPoint javadoc literally and turn the ArithmeticException into a QueryNodeException.

Trade-offs

A parse error instead of an empty result for a query whose documented match set is empty; applications that generate such bounds would start failing loudly. The documentation does not rule this option out, and a maintainer may well prefer it: the bound cannot be made inclusive, and rejecting it is what the javadoc's Math.addExact advice does. The regression test would assert the exception instead of 0 hits.

Method: semi-formal (a code-reading hypothesis checked by a Dafny proof obligation).

• Finder (study experiment on points and BKD query evaluation, 2026-10-22, main 7cecf79523). Bounds.dfy models Java int/long arithmetic with explicit Wrap32/Wrap64. The obligations ParserExclusiveLowerInt, ParserExclusiveUpperInt and ParserExclusiveLowerLong failed: for L = 2147483647 the real exclusive range is empty, but Wrap32(L + 1) = MIN matches. Then a 3-test JUnit.
• Verification. An independent study verifier wrote its own 9-case test with 7 controls (5 seeds) and a 4-guard counterfactual patch; a follow-up found the open-bound sibling; the hunt added a one-test minimal repro, a reproducer, a refute review, a second adjudication, a history and a prior-report follow-up (see the checks below).