BinaryPoint's one-dimensional exact and range queries keep the caller's byte[], so refilling it changes queries already built

BinaryPoint.newExactQuery and the one-dimensional BinaryPoint.newRangeQuery build a PointRangeQuery whose bounds are the caller's own byte[]: BinaryPoint.pack returns new BytesRef(point[0]) for one dimension (BinaryPoint.java:93-95), and PointRangeQuery stores the array it gets (PointRangeQuery.java:94-95). Matching, equals, hashCode and toString then read whatever the array holds now. A caller that encodes keys 1, 2 and 3 into one scratch buffer and ORs one exact query per key gets 1 hit instead of 3, before any search and with the query cache off; a range built for keys [1, 2] whose bound arrays are reused for key 3 matches 1 document instead of 2. The same factory copies the bounds for two or more dimensions, and a one-value newSetQuery keeps its value. Every release that has BinaryPoint (6.0.0 to 10.5.2) and main does this; no in-tree code calls these factories. Cloning the packed bounds for one dimension fixes it, and the point-query and document test suites pass with that change.

• BinaryPoint: a field that indexes a fixed-width binary value (or one per dimension) as a point. Its static factories build point queries: newExactQuery(field, byte[]), newRangeQuery(field, byte[], byte[]), newRangeQuery(field, byte[][], byte[][]) and newSetQuery(field, byte[]...) (class javadoc, BinaryPoint.java:35-44).
• pack() (BinaryPoint.java:86-119): turns one value per dimension into one packed BytesRef. The field constructor uses it (:129-131), and so does the n-dimension range factory (:192-194).
• PointRangeQuery: the query the exact and range factories return. Its constructor takes the packed lower and upper bounds (PointRangeQuery.java:72-98).

1. For one dimension, pack() returns new BytesRef(point[0]) (BinaryPoint.java:93-95): a wrapper over the caller's array, no copy. For two or more it allocates a new array and copies each dimension in (:114-118).
2. newExactQuery(field, value) calls newRangeQuery(field, value, value) (:160-162), which wraps both arrays into byte[][] (:177-180) and calls the n-dimension factory, which passes pack(lowerValue).bytes and pack(upperValue).bytes to PointRangeQuery (:192-194). With one dimension these are the caller's arrays.
3. PointRangeQuery stores them as given (PointRangeQuery.java:94-95) and reads them each time it matches (:134-145, :267-268, :285-286, :600-601), hashes (:479-488), compares (:490-501) or prints (:503-530). Its getters return clones (:471-477), so the bounds cannot be changed through the query, only through the caller's own array.
4. So the query is consistent with itself but follows the caller's buffer: whatever the array holds when the query runs is what it matches.

• Three documents, keys 1, 2, 3 as 4-byte sortable ints, query cache off. Encode each key into one scratch buffer and OR one newExactQuery per key: 1 hit instead of 3 (the same loop with one-value newSetQuery: 3).
• Build newRangeQuery for keys [1, 2], then write key 3 into both bound arrays: 1 document instead of 2. The two-dimension overload built from the same arrays: 2.
• Build newExactQuery for key 1, write key 2 into the array: the query prints key:[binary(80 0 0 2) TO binary(80 0 0 2)] instead of binary(80 0 0 1).
• With one-byte keys (the diagram's example): two exact queries from one scratch array, OR-ed, count 1 instead of 2, and q1.equals(q2) is true with the same hashCode; a range built for [1, 2] counts 0 after 9 is written into its arrays.

• Who is exposed. Applications that build one-dimensional BinaryPoint exact or range queries from a byte[] they later refill or reuse while the query is still in use. Typical shape: fixed-width binary keys (sortable ints, hashes, ids) encoded into one scratch buffer in a loop to OR several exact queries. NumericUtils.intToSortableBytes(value, result, offset) writes into a caller-supplied array, so the loop is an ordinary pattern.
• Default vs opt-in. No special configuration: a plain new IndexWriterConfig() and new IndexSearcher(reader) (the test framework picks a random codec and directory for each seed, and every seed used failed the same way); no query cache needed (the repro turns it off and builds every query before the first search); no index-size prerequisite (3 documents). The typed point classes (IntPoint, LongPoint, ...) take numbers and build their own arrays; BinaryPoint with two or more dimensions and newSetQuery copy. No file outside the tests calls BinaryPoint.newExactQuery or newRangeQuery.
• Silent. Wrong matches (an OR loses hits, a range matches another range), no exception, no log line, nothing written to the index. Queries built for different keys become equals with the same hashCode.
• With a query cache. The hunt's cache probe (LRUQueryCache, 16 and 1 partitions) served 0 wrong hits to a freshly built twin; after a key's hashCode drifts, 32 bytes of accounted query RAM stayed after cleanUp. Not counted as impact.
• How likely. Rare: it needs the reuse pattern on a less-used API, and the recorded searches found no report since 6.0.0 (2016). Once the pattern is used, the wrong results are deterministic.

# Lucene main 645d4fe14a20, assertions on (-ea), seed DEADBEEF: 1 test(s) run, 1 failed
    => java.lang.AssertionError: expected:<1> but was:<0>
       org.junit.Assert.fail(Assert.java:89)
       org.junit.Assert.failNotEquals(Assert.java:835)
       org.junit.Assert.assertEquals(Assert.java:647)
       org.junit.Assert.assertEquals(Assert.java:633)
       org.apache.lucene.document.TestBinaryPointExactQueryOwnsValue.testRefillingCallerArrayDoesNotChangeBuiltQuery(TestBinaryPointExactQueryOwnsValue.java:42)

• One method, two answers. newRangeQuery(String, byte[][], byte[][]) owns its bounds for two or more dimensions and shares the caller's array for one (BinaryPoint.java:93-95 vs :114-118, both reached from :192-194). Its javadoc (:182-191) does not mention the dimension count.
• Same class, same request. The class javadoc lists newExactQuery "for matching an exact 1D point" and newSetQuery "for matching a set of 1D values" (:38-40). A one-value newSetQuery(field, scratch) keeps its value after a refill (PointInSetQuery encodes it into its own storage); newExactQuery(field, scratch) does not. newExactQuery's javadoc: "@return a query matching documents with this exact value" (:158).
• Where Lucene shares, it says so. Field: "NOTE: the provided byte[] is not copied so be sure not to change it until you're done with this field" (Field.java:156-157); MultiPhraseQuery.Builder: "The array is not copied" (MultiPhraseQuery.java:111, :122). These factories carry no such note.
• The project's recorded direction. LUCENE-6369 (#7429): "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", superseded by #7648, "queries should now be immutable". LUCENE-6821 (#7879) made Term copy its BytesRef because building queries from shared bytes "is a bit trappy". LUCENE-7307 (#8361) made these very bounds clone on the way out (PointRangeQuery.java:471-477).
• Tests. No upstream test asserts the sharing. testPointRangeEquals and testPointExactEquals (TestPointQueries.java:2255-2265, :2324-2332) build the "other" query from ones.clone() instead of changing ones.
• History: an accident. pack()'s one-dimension shortcut came from LUCENE-6881 (f12cb52a3b8, 2015) for the field constructor. The query path started using pack() in LUCENE-7117/7118 (e1a1dbfabcc9, 2016), whose 14 comments discuss the byte[][] equals/hashCode bugs and never array ownership. Before that commit the factories kept the caller's arrays for every dimension count (unreleased code), so the two-dimension copy is a side effect of packing, not a design.

The strongest "works as designed" case, built by the refute review, the intended-lens review and the devil's advocate: no javadoc promises a copy; PointRangeQuery's constructor is protected and "Expert" and keeps its arrays; keeping caller values without a note is common in Lucene's query API: in the hunt's differential probe, 13 other query entry points follow a later write into the value they were given (the kNN query targets and the adaptive vector-similarity queries, TermRangeQuery for equals/hashCode, SortedSetDocValuesField.newSlowRangeQuery, SortedDocValuesField.newSlowExactQuery, SynonymQuery.Builder.addTerm(BytesRef, float), Intervals.term(BytesRef), RescoreTopNQuery.createFullPrecisionRescorerQuery, ConstKnnFloatValueSource), while PhraseQuery, TermInSetQuery and TermQuery copy; SortedSetDocValuesField.newSlowExactQuery keeps its bytes too (confirmed by running it); in LUCENE-6321 (#7382) a committer wrote "who is modifying term bytes? This seems like an abuse case"; 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 write goes into the caller's own array, before any query reaches a searcher and with no cache, through a public factory whose behaviour depends on the dimension count, so the IndexSearcher note does not apply. The same factory copies for two or more dimensions, so "the caller owns the array" is not the method's rule either. (A maintainer can still call a write into a retained array a modification of the query; that ownership question is what the issue asks them to settle.) The LUCENE-6321 remark continues "But maybe its a good idea to do a little "extra" clone work to make these core queries defensive", and the project then made Term copy. Users call the factories, not the protected constructor. Verdict: a defect (adjudication: confirmed, medium confidence; every verifier: real). The adjudication's own tier is Low because no in-tree code reuses such an array and the query-cache leg showed no wrong hits; the registry priority, medium, is a separate scale. The contract is implicit, which is why it is filed as an inconsistency and a robustness fix, with a javadoc note as the fallback.

One site fixes newExactQuery and both newRangeQuery overloads, because they all route through the n-dimension factory. pack() runs first, so its argument checks are unchanged. Each side is copied by its own dimension count; this also covers a mismatched input the method documents as rejected but does not check ({{1},{2}} against {{3,4}} is accepted on main), which is a separate issue. Workaround until a fix ships: pass a fresh array per query (scratch.clone()), or use newSetQuery for several exact values.

In newRangeQuery(String, byte[][], byte[][]), call pack() for both sides first, then clone() each side that has one dimension, and pass the results to PointRangeQuery. +11/-2 in BinaryPoint.java.

byte[] lower = pack(lowerValue).bytes;
byte[] upper = pack(upperValue).bytes;
// pack() returns the caller's array for one dimension (fine for the field constructor); copy
// it so that the query owns its bounds, as it already does for two or more dimensions
if (lowerValue.length == 1) {
  lower = lower.clone();
}
if (upperValue.length == 1) {
  upper = upper.clone();
}
return new PointRangeQuery(field, lower, upper, lowerValue.length) {

Trade-offs

• Cost: two small array copies per one-dimensional query; nothing changes on the indexing path.
• Behaviour change: code that, on purpose or not, retargets an already-built one-dimensional query by writing into its array would stop doing so; that has been observable since 6.0.0. This option limits the change to the BinaryPoint factory.
• pack() runs before the copy, so null and length errors stay IllegalArgumentException (an earlier draft read lowerValue.length first and turned a null argument into a NullPointerException; the refute review caught it).
• A one-condition variant (clone both sides when lowerValue.length == 1) behaves the same on valid input and was the version the earlier checks shadowed in.

What the checks validated

• Scratch worktree of main a9779ef3c193, gradle: the new test passes 3 of 3 with assertions on and off; TestBinaryPointQueryArrayOwnership, TestPointQueries, TestPointValues and TestFieldExistsQuery: 4 suites, 121 tests, 2 skipped, 0 failures, assertions on and off.
• Every org.apache.lucene.document suite plus TestPoint* and TestPointValues: 62 suites, 589 tests, 28 skipped, 0 failures.
• :lucene:core:check -x test passes (checkGoogleJavaFormat, ecjLintMain, ecjLintTest, forbiddenApisMain, forbiddenApisMain25, forbiddenApisTest).
• Standalone runner with the fix shadowed: the finder's test 2/2, the independent reproducer's 6/6 and the devil's advocate's 4/4 pass.

this.lowerPoint = lowerPoint.clone(); this.upperPoint = upperPoint.clone(); in the protected constructor.

Trade-offs

Also covers subclasses outside Lucene that pass shared arrays. Every point range query then pays two extra copies, although IntPoint, LongPoint, the two-dimension BinaryPoint path and the other typed factories already pass fresh arrays, and it changes an Expert constructor's behaviour, so the behaviour change of option A reaches every PointRangeQuery subclass. Not run.

Drop the one-dimension shortcut in pack().

Trade-offs

Not recommended: it adds one allocation and copy per one-dimensional BinaryPoint field instance on the indexing path (two or more dimensions are already copied), and the field would no longer share the caller's array, a field-side behaviour change, to fix a query-side problem. Field itself would still keep the array it is given. Not run.

Document on newExactQuery and the one-dimensional newRangeQuery that the provided byte[] is not copied, as Field does, and say on newRangeQuery(String, byte[][], byte[][]) that its arrays are kept when there is one dimension and copied when there are more.

Trade-offs

No behaviour change and no cost, but the same method still copies for two or more dimensions, and the encode loop still loses hits. The fallback if maintainers prefer no code change.

Method: semi-formal (the hunt's tier for tool-guided finds that are not a formal tool's own output), a hunt unit (search-side argument ownership), 2026-10-27, stock main jars.

• A bytecode ownership scan (an abstract interpretation of operand stack and locals over 17 module jars, with per-method keep summaries iterated to a fixpoint) listed PointRangeQuery's constructor as keeping its byte[] bounds.
• The unit's plan expected the BinaryPoint factories to pack a copy (a negative control). A differential probe over 20 query entry points (mutate after construction, two queries from one buffer, mutate after a cached search; 21 rows with one Sort row) showed the one-dimension BinaryPoint exact and range factories failing while the two-dimension control passed.
• The cause was then read in BinaryPoint.pack. The scan alone did not single out BinaryPoint; the signal came from the probe. A public-API JUnit test confirmed it, and independent AI tools reproduced, reviewed and judged it (see the checks).