Doc-values range queries compare equal on the caller's arrays, so queries built from reused arrays are merged although they match different ranges

Int/Long/Float/DoubleRangeDocValuesField.newSlowIntersectsQuery(field, min, max) returns a *RangeSlowRangeQuery that encodes min and max into a fresh byte array for matching, but keeps the caller's two arrays by reference and bases equals, hashCode and toString on them, overriding its parent class's correct equality over the encoded bytes. When the caller writes new bounds into the same arrays to build another query on the same field, as a loop over several windows through one scratch pair does, the first query keeps matching its old range but compares equal to, hashes like and prints the new one. BooleanQuery then merges or drops the "duplicate" clauses ([0,3] OR [5,6] gives 0 hits instead of 1 on a document with range [5,10]; a FILTER or a MUST_NOT window is lost; a FILTER plus MUST_NOT pair matches nothing), and a query cache can serve one query's hits for the other. No query cache is needed for the BooleanQuery effects. Affected: every release since the API appeared in 8.2.0, through 10.6.0, and main. The fix clones the two arrays in the four constructors.

1. The factory passes the caller's arrays through. IntRangeDocValuesField.newSlowIntersectsQuery returns new IntRangeSlowRangeQuery(field, min, max, queryType) (IntRangeDocValuesField.java:58-72; Long, Float and Double the same). Its javadoc says only that the query "doesn't leverage indexing and may be slow" (:64-69).
2. Matching uses a copy made at construction. The constructor calls super(field, encodeRanges(min, max), ...) (IntRangeSlowRangeQuery.java:32), and encodeRanges writes into a new byte[] (:84-89). The parent BinaryRangeFieldRangeQuery stores it as queryPackedValue (:46-53) and matches against it (:123-129).
3. Identity uses the caller's live arrays. The constructor keeps this.min = min; this.max = max; (IntRangeSlowRangeQuery.java:34-35), and equals (:38-47), hashCode (:49-56) and toString (:65-77) read only those arrays. Long, Float and Double: :36-37, :40-49, :51-58, :67-79.
4. The parent's correct equality is overridden. BinaryRangeFieldRangeQuery.equals/hashCode compare the field and queryPackedValue (BinaryRangeFieldRangeQuery.java:66-82), exactly what matching uses; the four subclasses override both and never call super.
5. BooleanQuery de-duplicates on equality. Its constructor puts SHOULD and MUST clauses into Multisets and FILTER and MUST_NOT clauses into HashSets (BooleanQuery.java:129-141). A Multiset is a HashMap from query to count (Multiset.java:33, add at :80-84), so adding q2 finds the equal key q1, keeps it and counts it twice; a HashSet keeps only the first-added of two equal clauses. rewrite then merges the repeated SHOULD entries into one clause (:442-447, deduplicateClauses :714-758), drops duplicate FILTER and MUST_NOT clauses (:343-361), and returns MatchNoDocsQuery("FILTER clause also in MUST_NOT") when a FILTER equals a MUST_NOT clause (:365-369).
6. A query cache keys on the query, so an entry filled by one query is found for the other. Main installs no cache by default (IndexSearcher.java:82-84); 9.x and 10.x up to 10.6.0 have a static default LRUQueryCache that every IndexSearcher starts with unless the application replaces it.

One document with range [5,10]; min = {0}, max = {3}, build q1; min[0] = 5; max[0] = 6, build q2. q1 still matches [0,3] (0 hits) and q2 matches [5,6] (1 hit), yet q1.equals(q2) is true, the hash codes are equal and q1.toString() prints r:[[5] TO [6]]. Query cache off:

• q1 OR q2: 0 hits, expected 1 (the minimal repro);
• FILTER [5,6] AND FILTER [0,3]: 1 hit, expected 0 (with the clauses in the other order the answer happens to be right);
• FILTER [5,6] AND MUST_NOT [20,30]: 0 hits, expected 1;
• two MUST_NOT windows [0,3] and [5,6] next to MatchAllDocsQuery over four documents: 3 hits, expected 2.

With an always-caching LRUQueryCache, counting q1 and then q2 gives q2 0 hits, expected 1. All four types (Int, Long, Float, Double) fail the same way; the same tests with fresh arrays pass.

• What goes wrong. Silent wrong hit counts in both directions: a disjunction loses a window, a FILTER restriction or a MUST_NOT window is dropped (over-match), or a conjunction becomes "match nothing" (under-match). No error is raised.
• Configuration. An otherwise-default IndexWriterConfig with the default codec (the test pins it with TestUtil.getDefaultCodec()) and a plain IndexSearcher. The BooleanQuery effects need no query cache. Scale does not matter: the repro uses one document.
• What it takes. The caller writes into the min/max arrays after passing them to a factory and builds another query of the same type on the same field (equals compares the field, IntRangeSlowRangeQuery.java:44). Building each query from fresh arrays is safe.
• Through a query cache. On 9.x and 10.x the static default LRUQueryCache, on main a cache the application installs. Three more things must line up: the wrong entry is cached first; a later query of the same type, on the same field, has exactly the bounds the shared arrays hold; and the segment and query pass the default cache's checks (among them a segment of at least 10,000 documents and more than half the average segment size, and, for this kind of query, 5 uses). With the default 9.12.3 and 10.5.2 cache and no configuration, on one 12,000-document segment, a scratch-built query that filled the cache made a later, correctly built query with exactly those bounds on another IndexSearcher return 10,010 hits instead of 20. The extra documents are live documents of the same segment that match the first query's range; deleted documents and other segments are not involved.
• Misleading output. toString, used in logs, explanations and profiles, prints the caller's current arrays, not the range the query matches.
• How likely. Rare. Inside Lucene only TestRangeFieldsDocValuesQuery calls these factories, always with fresh arrays, and read-only code search found no call in Elasticsearch, OpenSearch or Solr (code search does not cover private code).

The class sits in org.apache.lucene.search, next to TestRangeFieldsDocValuesQuery, and uses nothing package-private. It pins the default codec, uses ByteBuffersDirectory, a plain IndexWriter and an IndexSearcher with the query cache turned off, so the wrong count comes from BooleanQuery de-duplication alone. It compiles on 9.1.0 and later (the org.apache.lucene.tests.* test-framework packages).

Regression test: this same test, as written. With the fix it passes, together with the core format, ECJ and forbidden-apis checks.

cp $REPRO/TestSlowRangeQueryReusedArrays.java $LUCENE/lucene/core/src/test/org/apache/lucene/search/
cd $LUCENE && ./gradlew :lucene:core:test --tests org.apache.lucene.search.TestSlowRangeQueryReusedArrays -Ptests.seed=DEADBEEF
# assertions off fails the same way: add -Ptests.asserts=false (the recorded runs added --offline --no-daemon)

# gradle, scratch worktree of 645d4fe14a20, seed DEADBEEF, assertions on
TestSlowRangeQueryReusedArrays > testDisjunctionBuiltFromReusedArrays FAILED
    java.lang.AssertionError: expected:<1> but was:<0>
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:19BC7A99D7656228]:0)
        at org.junit.Assert.fail(Assert.java:89)
        at org.junit.Assert.failNotEquals(Assert.java:835)
        at org.junit.Assert.assertEquals(Assert.java:647)
        at org.junit.Assert.assertEquals(Assert.java:633)
        at org.apache.lucene.search.TestSlowRangeQueryReusedArrays.testDisjunctionBuiltFromReusedArrays(TestSlowRangeQueryReusedArrays.java:51)

# standalone runner, seed DEADBEEF: the same message, 1 of 1 failed each
main 645d4fe14a20 (-ea, -da); 10.6.0, 10.5.2, 10.0.0, 9.12.3, 9.1.0 (-ea)

• The equality contract. Query#equals "is required so that QueryCache works properly", and "Typically a query will be equal to another only if it's an instance of the same class and its document-filtering properties are identical to those of the other instance" (Query.java:95-107). After reuse, two queries that match 0 and 1 documents are equal.
• Internal inconsistency. The query already snapshots its bounds for matching, and BinaryRangeFieldRangeQuery already compares that snapshot (BinaryRangeFieldRangeQuery.java:66-82); only the four subclass overrides read the live arrays. That holds whether or not reusing arrays is good practice.
• Siblings and documentation. IntRange.newIntersectsQuery encodes into fresh bytes (IntRange.java:202-204, :254); NumericDocValuesField.newSlowSetQuery and SortedNumericDocValuesField.newSlowSetQuery clone their values (NumericDocValuesField.java:127-128, SortedNumericDocValuesField.java:125-126); the public Term(String, BytesRef) constructor copies its bytes (Term.java:50-54). Some APIs that keep a caller's array say so: MultiPhraseQuery.Builder.add(Term[]), "The array is not copied or mutated, the caller should consider it immutable subsequent to calling this method" (MultiPhraseQuery.java:109-113). Others keep it without saying so: KnnFloatVectorQuery and KnnByteVectorQuery store the caller's target array (KnnFloatVectorQuery.java:97, KnnByteVectorQuery.java:96), but they match and compare on that same array, so they stay consistent with themselves. The four factories document nothing, and their queries are not consistent with themselves.
• History. The classes came with LUCENE-8362 (#9409, 2019). Its review asked only for Arrays.equals/Arrays.hashCode instead of identity on the arrays; nobody discussed reuse or copying. TestRangeFieldsDocValuesQuery always passes fresh arrays and never checks equals.
• Precedent. #12158 (merged 2023) fixed a factory that passed the caller's array into a query by cloning it in KeywordField#newSetQuery. LUCENE-6369 (#7429, 2015): "It is very important for the query cache that queries be either immutable or clone deeply so that they cannot change after having been put into the cache"; it was closed Won't Fix in 2015 as "Superseded by #7648: queries should now be immutable" (LUCENE-6590).

The strongest case for "intended" (cross-model reviews, a devil's-advocate verifier and the adjudication built it): Java APIs do not promise defensive copies; KnnFloatVectorQuery also keeps the caller's target array (KnnFloatVectorQuery.java:97); in LUCENE-6321 (#7382, 2015) Robert Muir called modifying term bytes after building a query "an abuse case, and its gonna be problematic everywhere in lucene apis if you do this"; and IndexSearcher.setQueryCache says "When using a query cache, queries should not be modified after they have been passed to IndexSearcher" (IndexSearcher.java:268-269).

Why it fails: the caller never calls anything on a query after building it, the arrays change before either query reaches a searcher, and the BooleanQuery results are wrong with no cache, so the setQueryCache note does not apply. Still, because q1 keeps the arrays, a maintainer can fairly call the write an indirect change to q1; the next point does not depend on how that write is read. In the Knn and Term cases one input drives both matching and equality, so those queries stay self-consistent; here matching is snapshotted and equality is not. LUCENE-6321 (#7382) was closed Won't Fix "in favor of #7429" (LUCENE-6369), whose goal is immutable or deeply cloned queries; #7429 was in turn closed Won't Fix as "Superseded by #7648: queries should now be immutable". Through the arrays they keep, these four queries are not immutable; the fix makes them so. The earlier cross-model reviews (two separate OpenAI GPT-5.6 runs with different lenses) rated the works-as-designed case weak, a later cross-model fact check of this doc rated it moderate for the indirect-change reading above, and the independent reproducer, the devil's-advocate verifier and the adjudication rejected it. The reach is narrow, so "low priority" is a fair maintainer reply; "not a bug" is much harder to justify.

Two fixes were validated through gradle in a scratch worktree of 645d4fe14a20; the recommended one is the complete one. A documentation-only change was not built.

In IntRangeSlowRangeQuery, LongRangeSlowRangeQuery, FloatRangeSlowRangeQuery and DoubleRangeSlowRangeQuery, store copies of the caller's arrays. Then equals, hashCode and toString all describe the range the query matches.

IntRangeSlowRangeQuery(String field, int[] min, int[] max, RangeFieldQuery.QueryType queryType) {
  super(field, encodeRanges(min, max), IntRange.BYTES, min.length, queryType);
  this.field = field;
  this.min = min.clone(); // was: this.min = min;
  this.max = max.clone(); // was: this.max = max;
}

Trade-offs

• Cost. Two small array copies (one value per dimension) per query construction; matching is unchanged.
• Placement. The constructors are package-private and only the four factories call them (*RangeDocValuesField.java:61), so cloning in the factories, as #12158 did for KeywordField#newSetQuery, would be equivalent today; the constructor also covers any future caller.

What the checks validated

• Gradle, scratch worktree of 645d4fe14a20, OpenJDK 25.0.3, seed DEADBEEF (2026-10-31). Stock: the repro fails. With the fix: the repro and TestRangeFieldsDocValuesQuery pass with assertions on and off (7 tests each way).
• :lucene:core:test over org.apache.lucene.document.* plus the repro, TestRangeFieldsDocValuesQuery, TestBooleanRewrites and TestLRUQueryCache: 63 classes, 576 tests, 29 skipped, 0 failures.
• checkGoogleJavaFormat, ecjLintMain, ecjLintTest (with the repro test in place), forbiddenApisMain, forbiddenApisTest: pass.
• Earlier, on ea57360912ed with the fix shadowed: the finder's, the independent reproducer's, the devil's-advocate verifier's, the cross-model reviewers' and the security probe's tests all pass.

Delete the four equals/hashCode overrides (and the then-unused java.util.Objects import), so BinaryRangeFieldRangeQuery's equality over the encoded bytes applies (-84 lines).

Trade-offs

toString still prints the caller's live arrays, so a query can still print a range it does not match. It can be combined with the clone fix, but the clone fix alone is enough.

What the checks validated

Gradle on 645d4fe14a20: the repro and TestRangeFieldsDocValuesQuery pass (7 tests); checkGoogleJavaFormat and ecjLintMain pass.

Add a javadoc note to the four factories.

Trade-offs

Makes the current behaviour official but leaves the query internally inconsistent, and keeps the silent BooleanQuery and cache effects for anyone who misses the note.

Method: non-formal (code reading, then public-API JUnit tests).

• A hunt unit on document field factories was writing a bounded-exhaustive differential test of the doc-values range-query path. That harness builds fresh arrays for every query, so it cannot see this defect.
• While writing it, the finder read the *RangeSlowRangeQuery classes and saw that equals/hashCode read the caller's arrays while matching reads an encoded copy. A JUnit on the stock main jars confirmed it (3 of 3 tests fail with assertions on and off, and on 10.5.2 and 9.12.3).
• An independent reproducer, a devil's-advocate verifier (who added the scratch-array OR loop), cross-model reviews (OpenAI GPT-5.6) and an adjudication checked it; a follow-up ran it from 8.1.1 to main and probed the cache path; the repro was minimized to one test.