DoubleRange and FloatRange accept the bounds [0.0, -0.0] and store them inverted, so INTERSECTS queries silently miss the document

DoubleRange.verifyAndEncode rejects min > max with Java's primitive > (DoubleRange.java:144 on main 645d4fe14a20; the same in FloatRange.java:144), for which 0.0 > -0.0 is false, and then stores the bounds with NumericUtils.doubleToSortableLong / floatToSortableInt, whose order is Double#compareTo / Float#compareTo, where -0.0 sorts below +0.0. So [+0.0, -0.0] is accepted and stored with min above max; a Z3 model proves it is the only such pair among non-NaN bounds (NaN is rejected separately). RangeFieldQuery's INTERSECTS test (query.max >= doc.min && query.min <= doc.max) is an overlap test only for ordered ranges, so such a document is WITHIN [0, 0] and INTERSECTS [-1, 1] but does not INTERSECT [0, 0], which fits no reading of signed zero. The doc-values fields and their slow queries, range-on-range facets and query bounds go through the same check. Every release since 6.2.0 is affected (all 89 through 10.5.2 executed, 10.6.0 by reading). Validating with Double.compare / Float.compare (6 lines in 5 files) rejects the pair like every other inverted range; the minimal test and 9 more range suites pass with it.

1. The check. new DoubleRange(name, min, max) (DoubleRange.java:59-61) calls setRangeValues (:84), which calls verifyAndEncode (:105). After the NaN checks it rejects min[d] > max[d] (:144) with "min value (..) is greater than max value (..)". With Java's >, 0.0 > -0.0 is false, so [0.0, -0.0] passes.
2. The encoding. It then stores each bound with NumericUtils.longToSortableBytes(NumericUtils.doubleToSortableLong(val), ...) (:148-149, :153-156). The sort order of doubleToSortableLong "is defined by Double#compareTo" (NumericUtils.java:37-43; floatToSortableInt by Float#compareTo, :60-66), where -0.0 < 0.0. So the stored min (+0.0) is above the stored max (-0.0). FloatRange is the same code (FloatRange.java:144, :155).
3. The relations. INTERSECTS matches when query.max >= doc.min && query.min <= doc.max (RangeFieldQuery.java:104-115). For the query [0.0, 0.0] the second test is +0.0 <= -0.0, false, so no match; for [-1, 1] both hold. WITHIN (:147-158) and CONTAINS (:190-201) compare min with min and max with max, and still match.
4. Other paths. DoubleRangeDocValuesField's constructor encodes through DoubleRange.encode (DoubleRangeDocValuesField.java:33), its slow queries call DoubleRange.verifyAndEncode (DoubleRangeSlowRangeQuery.java:89), and DoubleRangeOnRangeFacetCounts calls it too (:19, :90). Their own argument checks use the same primitive >: DoubleRangeDocValuesField.java:84, FloatRangeDocValuesField.java:84, and the range-on-range facet DoubleRange.java:58 and :117.
5. Only this pair. For non-NaN values, a > b and Double.compare(a, b) > 0 differ only for a = +0.0, b = -0.0. A Z3 floating-point and bit-vector model of the check and the encoding, for non-NaN bounds (NaN is rejected before this check, DoubleRange.java:136-143), proves [+0.0, -0.0] is the only accepted pair stored inverted, and that with a Double.compare check no accepted pair is stored inverted.

FloatRange gives the same counts for the queries run (own bounds, [0, 0], [-1, 1]). Doc values: DoubleRangeDocValuesField.newSlowIntersectsQuery [0, 0] = 0, [-1, 1] = 1, own bounds = 0; FloatRangeDocValuesField misses its own bounds too. Range-on-range facets: WITHIN={zero=1, wide=1} but INTERSECTS={zero=0, wide=1}. As query bounds: a document [0.0, 0.0] is matched by newContainsQuery(r, {0.0}, {-0.0}) but not by newIntersectsQuery with the same bounds. A plain main() probe outside the test framework, with the production default codec, prints the same DoubleRange counts on main and 10.5.2.

• Who. Applications that index or query DoubleRange / FloatRange (points or doc values) or use range-on-range facets, with bounds that can be exactly +0.0 then -0.0. By code reading (not executed), Elasticsearch passes double_range / float_range document bounds straight to new DoubleRange / new FloatRange with no ordering check of its own.
• How it arises. Math.ceil(x) is -0.0 for -1 < x < 0 (documented by the JDK), and -x is -0.0 for x = 0.0, so new DoubleRange(f, {0.0}, {Math.ceil(-0.3)}) looks like [0, 0] to its author. Upstream tests never build the pair: their generator orders bounds with Math.min / Math.max and never yields -0.0.
• Effect. Silent wrong results, mostly missed matches for documents stored with these bounds (and, with [0.0, -0.0] as a query's bounds, for valid documents such as [0.0, 0.0]), and relations that contradict each other. No exception, no index corruption: CheckIndex is clean on indexes of about 21,000-24,500 documents with a quarter of them inverted.
• Not affected. [-0.0, +0.0], [0.0, 0.0], [-0.0, -0.0] and every pair without both signed zeros.
• Releases. Every release since 6.2.0; default codec and configuration; any index size.

The data are fixed and the test chooses no codec (new IndexWriterConfig(), ByteBuffersDirectory, new IndexSearcher(reader)). As a LuceneTestCase it still runs under the test framework's randomized setup: the gradle runs used codec=Asserting(Lucene104), a random maxPointsInLeafNode, RandomSimilarity, locale and time zone. The result does not depend on that: seeds DEADBEEF and 5EED1234 give the same failure, and a plain main() probe outside the test framework, with the production default codec, also counts 0 on main and 10.5.2. It fails the same way on the 10.5.2 and 9.12.3 release jars.

The other faces of the bug (FloatRange, the doc-values slow query, range-on-range facets, query bounds) share the root cause and the fix and are left out of the minimal test; they are in the table under "The finding in 30 seconds".

As a regression test it is the same test, except that Lucene's ecj lint rejects the unused catch parameter name rejected and accepts it written as _ (catch (IllegalArgumentException _)).

cp $REPRO/TestDoubleRangeSignedZeroBounds.java $LUCENE/lucene/core/src/test/org/apache/lucene/document/
cd $LUCENE && ./gradlew :lucene:core:test --tests org.apache.lucene.document.TestDoubleRangeSignedZeroBounds -Ptests.seed=DEADBEEF -Ptests.asserts=true
# also with -Ptests.asserts=false

TestDoubleRangeSignedZeroBounds > testAcceptedZeroToNegativeZeroIntersectsZero FAILED
    java.lang.AssertionError: INTERSECTS [0.0, 0.0] hits for an indexed DoubleRange [0.0, -0.0] expected:<1> but was:<0>
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:5F92A52E027EB78A]:0)
        ...
        at org.apache.lucene.document.TestDoubleRangeSignedZeroBounds.testAcceptedZeroToNegativeZeroIntersectsZero(TestDoubleRangeSignedZeroBounds.java:46)
:lucene:core:test (FAILURE): 1 test, 1  failure

# the same with -Ptests.asserts=false, on the standalone runner (-ea, -da) and on the 10.5.2 and 9.12.3 jars (-da)
# with the recommended fix: the test passes (1 test, 0 failures), assertions on and off

• Deliberate validation. verifyAndEncode throws "min value (..) is greater than max value (..)" (DoubleRange.java:144-147); the upstream test TestDoubleRangeField.testMinGreaterThanMax ("min cannot be greater than max", on core DoubleRange, in the sandbox test tree, :71-80) asserts it. Executed: [MIN_VALUE, 0.0], [0.0, -MIN_VALUE] and [-0.0, -MIN_VALUE], the pairs adjacent in Double#compare order, are all rejected; [+0.0, -0.0] is the only one let through (also proved with Z3).
• Witnesses against both readings (executed). Numeric reading (-0.0 == 0.0, the point zero): it must INTERSECT [0, 0], and does not; a query [0.0, -0.0] misses a document [0.0, 0.0]. Lucene's order (-0.0 < 0.0, an empty range): it could not INTERSECT [-1, 1] (it does), and would be WITHIN [1, 2] (it is not); a query [0.0, -0.0] intersects a document [-1, 1].
• Contract. newIntersectsQuery: "@return query for matching intersecting ranges (overlap, within, or contains)" (DoubleRange.java:198, FloatRange.java:198). Lucene's documented order for floating-point values: "Range comparisons are consistent with Double#compareTo" (DoublePoint.java:213, :235; documented since LUCENE-7061, 6.0.0), and #8645 (LUCENE-7594): float/double points "are supposed to be consistent with Double/Float.compare, so +0 is supposed to compare greater than -0". The check uses a different order from the encoding.
• History. The check and the encoding were written together in LUCENE-7381 (2016-07). By then DoublePoint and FloatPoint already documented that range comparisons follow Double#compareTo (LUCENE-7061, 2016-03, in 6.0.0). LUCENE-7594 (2016-12) later made the exclusive-bound helpers follow that order, and its issue states the intent (+0 above -0). The range-field check was never revisited. No discussion of signed zero in the introducing issues or in later range-field discussions.
• Precedent. LUCENE-7738, "Fix min/max verification bug in InetAddressRange" (2017).

Strongest case (the works-as-designed review and the devil's-advocate verifier): under Lucene's documented Double#compare order, [+0.0, -0.0] is an inverted, empty range, so the caller passed bad bounds. Read that way, "WITHIN and CONTAINS itself but not INTERSECTS itself" is exactly what an empty set does, and Lucene's point range queries accept inverted bounds too: DoublePoint.newRangeQuery(f, 0.0, -0.0) matches nothing without an error (executed). No javadoc on the range fields defines signed-zero semantics, and the upstream test oracle compares bounds with primitive operators, so neither reading is pinned down by tests.

Why it fails: the range fields, unlike point queries, reject inverted ranges on purpose, and this is the only inverted pair they accept; the results fit neither reading; nothing documents a precondition that bounds must be ordered in Double#compare order.

Option A was built and run in a scratch worktree of 645d4fe14a20 with gradle; option B was run on the minimal test only; option C was not built. The choice is upstream's: A changes what indexes today, B rewrites stored bounds.

Replace min > max by Double.compare(min, max) > 0 (Float.compare for floats) in DoubleRange.verifyAndEncode and FloatRange.verifyAndEncode (:144 each), the doc-values fields' checkArgs (:84 each) and the range-on-range facet DoubleRange (:58, :117). The two verifyAndEncode lines alone cover every path (the doc-values constructors and slow queries and the facet counting all call them). Of the other four, the doc-values checkArgs lines make the slow-query factories reject with their own message ("min should be less than max"), and the facet lines make the facet range reject when it is built instead of when counting. The doc-values constructors reject through verifyAndEncode either way: super(field, DoubleRange.encode(min, max), ...) at :33 runs before checkArgs at :34 (executed with the fix shadowed).

-      if (min[d] > max[d]) {
+      if (Double.compare(min[d], max[d]) > 0) {
         throw new IllegalArgumentException(
             "min value (" + min[d] + ") is greater than max value (" + max[d] + ")");

Trade-offs

• A behaviour change: code that indexes [0.0, -0.0] today starts to get an IllegalArgumentException, so it likely needs a CHANGES entry. Documents already indexed that way stay inverted until reindexed.
• For non-NaN bounds Double.compare is the order the encoding uses, so it rejects exactly the pairs that would be stored inverted: no ordered pair is newly rejected. The query-side case becomes a clean exception too.
• It matches how at least one downstream server validates its own range-query bounds (from.compareTo(to) > 0, read, not executed).

What the checks validated

• Stock + test: fails with assertions on and off (gradle).
• + fix: the test and 9 suites pass with assertions on and off: core TestDoubleRange, TestFloatRange, TestDoubleRangeFieldQueries, TestFloatRangeFieldQueries, TestRangeFieldsDocValuesQuery; facet TestRangeOnRangeFacetCounts, TestRangeFacetCounts; sandbox TestDoubleRangeField, TestRangeFacet (97 tests with the new one, 2 skipped, 0 failures).
• + fix: :lucene:facet:check without tests passes (formatting, ecj lint, forbidden APIs); :lucene:core:check passes once the test's unused catch parameter is written as _ (ecj rejects the name rejected).
• With the 5 patched files shadowed on the standalone runner: the independent reproduction's 9 tests and the finder's 6 tests (double, float, both doc-values fields, query bounds, facets) pass.
• Not run: the full Lucene test suite, nightly tests.

Keep the primitive check; when Double.compare(min, max) > 0 (which then means [+0.0, -0.0]), store [-0.0, +0.0], the numeric point zero (+6 lines in DoubleRange.verifyAndEncode).

Trade-offs

Indexing keeps working, but the stored bounds differ from the input (getMin/getMax return -0.0, +0.0), the same change is needed in FloatRange and the facet code, and it adopts the numeric reading of signed zero for this one pair while Lucene's documented order is Double#compare.

What the checks validated

The minimal test passes with this DoubleRange shadowed (assertions on). Not run against the suites.

Remove signed zero from range fields entirely. Not built.

Trade-offs

Changes results for valid ranges that start or end at -0.0 today (for example a document [-1, -0.0] would start to match INTERSECTS [0.0, 1]) and mixes with documents already indexed.

Method: bounded-exhaustive translation validation (semi-formal), a hunt unit. The harness built every 1-D and 2-D range over boundary value sets including ±0.0, ±MIN_VALUE, ±MAX_VALUE, ±Inf and NaN, and checked each relation (INTERSECTS, WITHIN, CONTAINS, CROSSES) across points, doc values, both, multi-valued points, conjunctions, count() and range-on-range facets, in 8 index variants, against exact range semantics. Code reading while writing the harness suggested that the primitive check and the sortable encoding disagree on signed zero; the harness then reported the range [0.0, -0.0] as accepted but invalid for double and float: 2,376 of 10,304 double and 1,992 of 8,512 float 1-D checks mismatched, every one involving that range, and 0 of 1,742,048 2-D checks once it is excluded.

A Z3 floating-point and bit-vector model of the check and the encoding, for non-NaN bounds (NaN is rejected separately), then proved that [+0.0, -0.0] is the only accepted pair stored inverted (Q2 unsat), that today's check never rejects a pair whose stored order is ordered (Q3 unsat), and that a Double.compare check leaves no accepted pair inverted (F1 unsat); a mutant of the encoding is caught (M1 sat). The first signal came from the exhaustive check, so this is not a formal-tool-first finding.