LongRangeOnRangeFacetCounts and DoubleRangeOnRangeFacetCounts throw ArrayIndexOutOfBoundsException when given no ranges

LongRangeOnRangeFacetCounts and DoubleRangeOnRangeFacetCounts (facet module, since 9.5.0) count, for each requested range, the documents whose indexed range intersects, contains, lies within or crosses it. Their constructors take the requested ranges as varargs and document no minimum. Called with no ranges, every public constructor throws ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0, because the private helper getEncodedRanges evaluates new byte[ranges.length][2 * Long.BYTES * ranges[0].dims] without checking the length (LongRangeOnRangeFacetCounts.java:85, Double :88). It happens before any document is read, with assertions on and off. The classic LongRangeFacetCounts and DoubleRangeFacetCounts, which the new classes were added to mirror, return an empty result for the same request on purpose and test it; the multi-dimensional sibling MatchingFacetSetsCounts rejects empty input with an IllegalArgumentException. Nothing is miscounted: only the kind of error is wrong. The two getEncodedRanges helpers and their constructor call sites are unchanged since #11901 (later commits touched only the base class), so every release from 9.5.0 to 10.6.0 and main has it. A three-line guard fixes it, either with an IllegalArgumentException or with an empty result.

• Range-on-range faceting (org.apache.lucene.facet.rangeonrange): each document stores a range (1 to 4 dimensions) in a LongRangeDocValuesField or DoubleRangeDocValuesField; the counter counts, per requested LongRange / DoubleRange, the hits whose stored range matches it under a RangeFieldQuery.QueryType.
• Encoded ranges: before counting, each requested range is packed into a byte array of 2 * BYTES * dims bytes (min and max per dimension). The counter takes the number of dimensions from the first requested range.

1. Both public constructors of LongRangeOnRangeFacetCounts (LongRangeOnRangeFacetCounts.java:42-53 and, with a fastMatchQuery, :67-82) pass getEncodedRanges(ranges) as an argument of super(...) (:51, :80), so the helper is the first code that sees the list.
2. getEncodedRanges (:84-90) runs new byte[ranges.length][2 * Long.BYTES * ranges[0].dims] (:85). Java evaluates both dimension expressions before it allocates, so with no ranges the read of ranges[0] throws ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0. Nothing checks the list first.
3. DoubleRangeOnRangeFacetCounts has the same code (DoubleRangeOnRangeFacetCounts.java:87-93, the read at :88).
4. The base class RangeOnRangeFacetCounts also reads encodedRanges[0], in an assert (RangeOnRangeFacetCounts.java:60) and in count() for the number of dimensions (:83). It is never reached today, but an empty-result fix must skip it too.
5. Assertions and data play no part: it is a JVM bounds check, before any document or doc value is read. The rest of the class copes with zero ranges (Range.getLabelsFromRanges maps an empty array to an empty one; getAllChildren and getTopChildren loop over the counts).

Twenty documents, document i storing [i, i+5]: one range [0, 2] with INTERSECTS counts 3. The classic new LongRangeFacetCounts("n", fc) with no ranges returns value 0, child count 0, no labels. new LongRangeOnRangeFacetCounts("lr", fc, INTERSECTS) throws at getEncodedRanges:85; an independent JUnit covering all four public constructors (Long and Double, empty varargs and explicit empty arrays) fails 4 of 6, its two controls passing, with assertions on and off.

• Who is hit. Users of LongRangeOnRangeFacetCounts / DoubleRangeOnRangeFacetCounts over LongRangeDocValuesField / DoubleRangeDocValuesField whose code builds the range list from request or configuration data that can be empty and passes it on unchecked (for example list.toArray(new LongRange[0]) on an empty list). All four public constructors fail, with or without a fastMatchQuery.
• What happens. The request fails at once with an exception whose stack trace points into Lucene (getEncodedRanges:85), not at the caller's empty list. Code that catches IllegalArgumentException for bad range input from this API (the range constructors and verifyAndEncode throw it for invalid bounds) does not catch this one.
• What does not happen. No wrong counts, no silent acceptance, no hang, no unbounded allocation, nothing written, no effect on the index, the reader or other requests. Same behaviour at any scale and with any data, with assertions on and off.
• How likely. Rare: it needs a dynamic, possibly empty range list, and no prior public report was found since the API was released in 9.5.0 (January 2023).
• Side note, same fix site, not part of this bug. getEncodedRanges also does not check that all ranges have the same number of dimensions. An independent side probe (assertions off) saw a 2-dimensional range followed by a 1-dimensional one return without error and count the 1-dimensional range 0 against a 2-dimensional document it overlaps in dimension 0, and the reverse order throw ArrayIndexOutOfBoundsException: Index 16 out of bounds for length 9. Mixing dimensions against one field is closer to misuse; it was not searched for prior reports.

The oracle does not pick between the fixes: an empty result (what the classic counters return) and an IllegalArgumentException (what MatchingFacetSetsCounts throws) both pass. The test covers the Long class; the Double class has the same one-line cause (:88) and fails the same way in the independent reproducer's and the devil's advocate's tests. It needs no randomness, so the seed does not matter, and it was compiled and run unchanged on 9.5.0, 10.6.0 and main (the releases in between ran a version-portable test).

As the regression test: the same test, for example as a new method in TestRangeOnRangeFacetCounts, with two cosmetic changes Lucene's static checks require: rename the unused catch parameter acceptable to _, as other facet tests do (ecjLintTest rejects it), and put the AssertionError on one line (google-java-format). With both, :lucene:facet:check -x test passes with either fix, and standalone the test still fails on stock main and passes with either fix, with assertions on and off. The unnamed _ needs Java 22 or later: fine on main (Java 25), but a backport to the 10.x line (Java 21) needs a named parameter that is used, or expectThrows. With fix A it can be tightened to expectThrows(IllegalArgumentException.class, ...); with fix B it can also assert that the value is 0, as the classic counters' empty-range tests do.

cp TestRangeOnRangeFacetCountsNoRanges.java $LUCENE/lucene/facet/src/test/org/apache/lucene/facet/rangeonrange/
cd $LUCENE && ./gradlew :lucene:facet:test --tests org.apache.lucene.facet.rangeonrange.TestRangeOnRangeFacetCountsNoRanges -Ptests.seed=DEADBEEF -Ptests.asserts=true
# assertions off: -Ptests.asserts=false instead (same result)
# without -Ptests.asserts, Lucene picks the mode from the seed (DEADBEEF picks off)

# gradle, main 645d4fe14a20, seed DEADBEEF, -Ptests.asserts=true (the same with -Ptests.asserts=false)
TestRangeOnRangeFacetCountsNoRanges > testNoRanges FAILED
    java.lang.AssertionError: expected an empty result or IllegalArgumentException, got java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:E938B2FB8B7E7074]:0)
        at org.apache.lucene.facet.rangeonrange.TestRangeOnRangeFacetCountsNoRanges.testNoRanges(TestRangeOnRangeFacetCountsNoRanges.java:36)

        Caused by:
        java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
            at org.apache.lucene.facet.rangeonrange.LongRangeOnRangeFacetCounts.getEncodedRanges(LongRangeOnRangeFacetCounts.java:85)
            at org.apache.lucene.facet.rangeonrange.LongRangeOnRangeFacetCounts.<init>(LongRangeOnRangeFacetCounts.java:51)
            at org.apache.lucene.facet.rangeonrange.TestRangeOnRangeFacetCountsNoRanges.testNoRanges(TestRangeOnRangeFacetCountsNoRanges.java:29)

• Contract. The class javadoc says "given a range (or list of ranges), this class will count all the documents ..." (LongRangeOnRangeFacetCounts.java:27-29); the constructors take varargs and document @param ranges ranges we want the counts of (:64), with no minimum and no @throws for an empty list. Neither counter class is tagged @lucene.experimental (Range is).
• Design intent. #11869 asks for "a corresponding RangeOnRangeFacetCounts" to LongRangeFacetCounts / DoubleRangeFacetCounts; the PR body of #11901: "Adds RangeOnRangeFacetCounts which supports double ranges and long ranges to mirror RangeFacetCounts". The classic counters support zero ranges on purpose since LUCENE-9946 (#127): ExclusiveLongRangeCounter.java:155-157 ("If no ranges were requested ..."), LongRangeCounter.java:195-197, and TestRangeFacetCounts.testEmptyRangesSingleValued / MultiValued (:383, :411) assert dim=field path=[] value=0 childCount=0 from getAllChildren and getTopChildren. TestRangeOnRangeFacetCounts (20 tests) has no empty-range counterpart; its randomized tests draw 1 to 100 ranges.
• Siblings. MatchingFacetSetsCounts.java:74-79 (LUCENE-10274, #841: a PR opened by the same author and co-written with Shai Erera and Greg Miller) throws IllegalArgumentException for null or empty matchers and for mixed dimensionality; core LongRange rejects empty min/max arrays with IllegalArgumentException("min/max range values cannot be null or empty"); this package's own Range.failNoMatch throws IllegalArgumentException.
• Precedent. CHANGES.txt, 9.11.1 Bug Fixes: "GITHUB#13493: StringValueFacetCounts stops throwing NPE when faceting over an empty match-set."
• History. The searched records did not reveal a minimum or any discussion of an empty list: no javadoc, test, CHANGES.txt or MIGRATE.md entry, none of the 62 inline review comments on #11901, and no mail found by the mailing-list searches.

The strongest case for "intended" (built by the refute reviewer, the second cross-model reviewer and the devil's advocate): zero ranges give the counter no dimensionality; the javadoc says "a range (or list of ranges)"; the base-class assert on encodedRanges[0] shows the author assumed a non-empty array; every upstream test passes at least one range; and the call already fails loudly, so it is in effect rejected and only the exception type is wrong.

Why it fails: it argues that zero ranges may be invalid input, not that an internal ArrayIndexOutOfBoundsException is the intended way to reject it. An assert states an internal invariant, not an API precondition; Lucene rejects bad public arguments with IllegalArgumentException, in this package and in MatchingFacetSetsCounts, the facet-sets counter of the same module; and the class was meant to mirror counters that accept the empty list. The repro accepts either an empty result or an IllegalArgumentException, so it does not overclaim. Verdict: not intended, a Low wrong-error defect. Residual risk: a maintainer may answer that only the exception type changes and rank it low priority, which is a priority answer, not a "by design" one.

Both options were run through gradle in a scratch worktree of 645d4fe14a20. A is recommended (the adjudication's choice: the smallest change, matching the explicit checks of its siblings); B is just as small and matches the classic counters.

In getEncodedRanges of LongRangeOnRangeFacetCounts (:84-85) and, identically, DoubleRangeOnRangeFacetCounts (:87-88).

   private static byte[][] getEncodedRanges(LongRange... ranges) {
+    if (ranges.length == 0) {
+      throw new IllegalArgumentException("ranges cannot be empty");
+    }
     byte[][] result = new byte[ranges.length][2 * Long.BYTES * ranges[0].dims];

Trade-offs

• The smallest change; it states the precondition the code already relies on (the number of dimensions comes from the first range) with the same exception type as MatchingFacetSetsCounts and the range constructors (the message wording differs).
• Callers that build the list at run time still have to special-case an empty list (with the classic counters they do not).
• Worth adding @throws IllegalArgumentException if no ranges are given to the four constructors. A null array still gives a NullPointerException; the sibling checks null too, which could be folded into the same if.
• Behaviour changes only for a call that fails today; one length check per constructor, nothing on the counting path.

What the checks validated

Gradle on 645d4fe14a20 (a scratch worktree, and the fact check's re-run with -Ptests.asserts=true): the repro fails on stock main and passes with A, each with assertions on and off. The whole facet module (:lucene:facet:test: 40 test classes, including the repro, TestRangeOnRangeFacetCounts with 20 tests, TestRangeFacetCounts and TestMatchingFacetSetsCounts) runs 307 tests, 0 failures; 7 skipped with assertions on (five nightly tests, one monster test and one @Ignored test), 8 with assertions off (the same plus one assertions-only test). :lucene:facet:check -x test (google-java-format, ecj lint, forbidden APIs) passes with A and the lint-clean regression test.

The finder's fix: getEncodedRanges returns new byte[0][] for no ranges, the base constructor skips count(), and its assert allows an empty array.

   // RangeOnRangeFacetCounts constructor
-    assert encodedRanges[0].length % (2 * numEncodedValueBytes) == 0;
+    assert encodedRanges.length == 0 || encodedRanges[0].length % (2 * numEncodedValueBytes) == 0;
 ...
-    count(field, hits.getMatchingDocs(), encodedRanges, numEncodedValueBytes, queryType);
+    if (encodedRanges.length > 0) {
+      count(field, hits.getMatchingDocs(), encodedRanges, numEncodedValueBytes, queryType);
+    }

   // LongRangeOnRangeFacetCounts and DoubleRangeOnRangeFacetCounts
   private static byte[][] getEncodedRanges(LongRange... ranges) {
+    if (ranges.length == 0) {
+      return new byte[0][];
+    }

Trade-offs

• Matches LongRangeFacetCounts / DoubleRangeFacetCounts (dim=field path=[] value=0 childCount=0) and #11901's stated aim to mirror RangeFacetCounts; callers with a dynamic list need no special case.
• Touches the base class as well (the assert and the count() call); the total stays 0 because no hit is counted, as in the classic counters' empty-range tests.
• An empty request is silently accepted, which can hide a caller bug.
• count() is skipped, so the hits, the doc values and any fastMatchQuery are never looked at. getAllChildren / getTopChildren return no children; getAllDims still returns a one-element list holding that empty FacetResult, and getSpecificValue stays unsupported, as for any range list.

What the checks validated

Same runs: the repro passes with assertions on and off, and the facet module runs 307 tests, 0 failures, with the same skips as for A (7 with assertions on, 8 off). :lucene:facet:check -x test passes with B and the lint-clean regression test. Earlier, with the fix shadowed into the stock jars, the independent reproducer's 6 tests passed 6 of 6, including getTopChildren giving value 0 and child count 0.

Method: non-formal (randomized differential testing, then executed JUnit tests). A hunt unit on facet taxonomy and range counting ran a randomized differential baseline on main ea57360912ed: new LongRangeOnRangeFacetCounts("f", fc, INTERSECTS) with no ranges threw ArrayIndexOutOfBoundsException, while new LongRangeFacetCounts("f", fc) returned an empty result. It was logged only as a low-value robustness lead.

On 2026-10-27 a later unit that turns such executed leads into public-API repros re-ran it on main a9779ef3c193 as a JUnit test with the differential oracle "the same result as the classic counter for the same empty request, or an explicit IllegalArgumentException" (the second outcome was added after the first cross-model review). Independent reproducers then wrote their own tests, ran the releases, and it was cut to the one-test repro on 645d4fe14a20.