Vector similarity queries tell the query cache they are cacheable, so one reader's or one search's result is served to another

FloatVectorSimilarityQuery, ByteVectorSimilarityQuery and Float16VectorSimilarityQuery (the last on main only) share one Weight that runs the vector search per segment and builds the matching set with three inputs that are not part of the segment: the reader's live docs, the searcher's timeout (on the approximate path), and the filter. Yet its isCacheable returns true. LRUQueryCache keys entries on the query and the segment core, which readers that differ only in deletions or doc-values updates share, so the first reader or search that fills the entry decides what the others get in non-scoring use (IndexSearcher#count, ConstantScoreQuery, a FILTER or MUST_NOT clause, also inside a scoring query): an older point-in-time reader misses a document only a newer reader deleted (2 instead of 3 in the diagram's example, 99 instead of 100 in the test), a search without a timeout gets an earlier timed-out search's empty result (0 instead of 100), and a filter on doc values updated in place lets through a document it now rejects (100 instead of 99). As a MUST_NOT clause the stale set excludes too little, so the parent query returns too much (1 instead of 0; 100 instead of 0 after a timeout). No error is raised. It has been in every release since the query appeared in 9.10.0 (the timeout case since 10.0.0); on 9.10.0-10.6.0 (10.6.0 by reading) the default IndexSearcher cache is enough, on main an application must install a cache.

• Query cache: LRUQueryCache stores, per query and per segment, the set of documents a non-scoring query matches, and reuses it. Its javadoc: "these cache and policy instances can be shared across several queries and readers" (LRUQueryCache.java:80). In 9.x and 10.x releases every IndexSearcher shares one static default cache with UsageTrackingQueryCachingPolicy (10.5.2 IndexSearcher.java:83-99); on main the default is null (IndexSearcher.java:84, #14187).
• Segment core: readers opened at different times, or wrapped views of one reader, share a segment's core when only its deletions or doc-values updates differ. The cache key uses the core (getCoreCacheHelper()), documented to cache "regardless of deletions"; readers with "different sets of deleted documents or doc values updates may be considered equal" (LeafReader.java:65-69). That is safe because an ordinary query's cached set ignores deletions and every search applies its own reader's live docs afterwards.
• Vector similarity query: new FloatVectorSimilarityQuery.Adaptive(field, target, resultSimilarity, decay, filter) matches every document whose vector similarity to target is at least resultSimilarity; decay 1 is the exact path, the default 0.5 an approximate graph search. @lucene.experimental.

1. createWeight (AbstractVectorSimilarityQuery.java:146) builds the filter Weight (:149-152) and captures searcher.getTimeout() with a TimeLimitingKnnCollectorManager (:154-156).
2. scorerSupplier reads leafReader.getLiveDocs() (:188) and builds the set from it on every path: exact "to guarantee completeness" (:192-198, AcceptDocs.fromLiveDocs at :196), approximate (:200-207, :204), and filtered (AcceptDocs.fromIteratorSupplier(filter iterator, liveDocs, maxDoc), :209-220). With a filter, decay 1 goes straight to an exact search (:228-233); otherwise a graph search runs first and its result is returned when it is complete or the timeout has fired ("Return partial results only when timeout is met", :239-243), else the Weight falls back to an exact scan (:244-248). Without a filter, the approximate path returns its partial result after a timeout as is (:200-207). So the timeout is read only on the approximate paths (decay below 1).
3. isCacheable(ctx) returns true (:252-255) and never asks filterWeight.isCacheable(ctx), whereas BooleanWeight and ConstantScoreQuery pass on their children's answer (BooleanWeight.java:273-285, ConstantScoreQuery.java:193-194).
4. LRUQueryCache trusts it (LRUQueryCache.java:816) and stores or finds the set under the query plus getCoreCacheHelper() (:827, :834); count returns the cached count for a reader without deletions (:892-924).
5. The next reader or search on that core gets the cached set intersected with its own live docs: it loses documents (live docs, timeout) or, through the filter, keeps one that no longer matches.

The top-k Knn*VectorQuery avoids this: it rewrites to DocAndScoreQuery, whose equals/hashCode include the reader context identity (DocAndScoreQuery.java:294-306) and whose createWeight rejects another reader (:170).

Diagram probe (one segment, docs 0-5, vector (i, 1), target (0, 1), threshold 0.15, an always-cache policy; main ea57360912ed, assertions on and off):

The doc's JUnit test (100 docs; 12,000 for the default settings): 99 instead of 100, 11,999 instead of 12,000, 0 instead of 100, 100 instead of 99; the FieldExistsQuery control is right. As a clause of a scoring BooleanQuery: FILTER 99 instead of 100; MUST_NOT 1 instead of 0 (older reader) and 100 instead of 0 (after a timed-out search) on main and 10.5.2, assertions on and off.

• Who is exposed. Non-scoring use (count, ConstantScoreQuery, a FILTER or MUST_NOT clause, also inside a scoring query) of FloatVectorSimilarityQuery, ByteVectorSimilarityQuery (both since 9.10.0) or Float16VectorSimilarityQuery (main only) with a query cache shared by several readers or searchers, plus one of: an older point-in-time reader searched after a newer one with fresh deletions on the same segment (a documented pattern: SearcherLifetimeManager "Keeps track of current plus old IndexSearchers", for example when "the user clicks next page", SearcherLifetimeManager.java:30, :48; also in-flight requests on the previous searcher after a refresh), or a soft-deletes view next to the raw view of one commit; a search with IndexSearcher#setTimeout whose timeout fires on the approximate path (10.0.0 and later); or a filter on a doc-values field updated in place.
• Not exposed. A direct scoring use, with the similarity query at the top of search(q, n): IndexSearcher wraps a Weight in the cache only when scores are not needed (IndexSearcher.java:979-981; the probe's scoring search(q, 10) is right). But FILTER and MUST_NOT clauses of a scoring BooleanQuery are created without scores (BooleanClause.java:84-86, BooleanWeight.java:58-59) and are cached, so they are exposed (executed). Also not exposed: separate caches, and main without an installed cache.
• Default or opt-in. On 9.10.0-10.5.2 no configuration is needed: IndexSearcher installs a static LRUQueryCache(1000, min(32 MB, heap/20)) with UsageTrackingQueryCachingPolicy, shared by every searcher. A zero-configuration probe (new IndexSearcher(reader), default IndexWriterConfig) fails on every release 9.10.0-10.5.2 and passes on main, where #14187 (in no release yet) removed the default cache. The query itself is @lucene.experimental, and a threshold vector query used as a filter is a niche use.
• Scale. None with an always-cache policy (6 documents). With the default policy the query becomes eligible on its 5th use (UsageTrackingQueryCachingPolicy.java:122-138) and is then cached on segments of at least 10,000 documents that are not much smaller than the average (LRUQueryCache.java:251-253, :278-296), if the worst-case entry fits and the lead-cost check passes (:792-807, :816-853). The doc's test installs these settings explicitly; its 12,000-document case goes wrong after 6 searches.
• How long. A wrong entry stays until LRU eviction, an explicit clearQuery, clearCoreCacheKey or clear (LRUQueryCache.java:443-457), or until its segment core closes, after a merge has replaced the segment and the last reader holding it is closed (:1133-1135). A poisoned timeout entry survived an NRT reopen with an unrelated deletion (0 instead of 11,999) in the security probe.
• What you see. No error, assertions on or off. Fewer hits or a lower count (live docs, timeout), or a document the filter rejects (filter); as a MUST_NOT clause, documents the clause should exclude (1 hit instead of 0; 100 instead of 0 after a timeout). It is not approximate recall: the exact path (decay 1) is affected and separate caches are right.
• Downstream (source reading only, nothing run there): OpenSearch's k-NN plugin builds these queries for radial search (already in 2.x releases); since 3.7.0 the server also sets IndexSearcher#setTimeout, and it uses a node-level LRUQueryCache, so the timeout case may reach its users on 3.7.0 and later. Solr's searcher disables Lucene's query cache; a code search found no use of these queries in Elasticsearch.

# Lucene main 645d4fe14a20, assertions on (-ea), seed DEADBEEF: 1 test(s) run, 1 failed
    => java.lang.AssertionError: expected:<2> but was:<1>
       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.search.TestVectorSimilarityQueryCache.testOlderReaderAfterNewerReader(TestVectorSimilarityQueryCache.java:58)

• The contracts. SegmentCacheable.java:24-35: "Objects that depend only on segment-immutable structures such as Points or postings lists can just return true"; "Objects that depend on doc values should return DocValues#isCacheable ... Updated doc values fields are not suitable for caching"; "Objects that are not segment-immutable ... should return false". LeafReader.java:65-69: the core cache helper caches "regardless of deletions"; readers with "different sets of deleted documents or doc values updates may be considered equal". QueryCache.java:26-30: the returned weight "will only be equivalent if scores are not needed". LRUQueryCache.java:893: "Our cache won't have an accurate count if there are deletions", so cached sets are meant to be computed without applying deletions.
• Upstream tests. testTimeout turns the cache off: "This query is cacheable, explicitly prevent it" (BaseVectorSimilarityQueryTestCase.java:623-624, added by #13285; copied into BaseExplicitVectorSimilarityQueryTestCase.java:503-504 by #16654). That avoids only the harmless direction, a cached full result hiding a timeout. The test framework installs query caches at random (LuceneTestCaseParent.java:2635, :2686), which is why the test must turn the cache off; the upstream similarity-query tests never reopen a reader, update doc values, or share one cache across readers or searchers. TestLRUQueryCache asserts that cached counts equal uncached ones across SearcherManager refreshes with deletions: the repro's oracle.
• History. #12679 (2023) added the query with isCacheable returning true; #13285 (2024) added the timeout input; neither thread discusses query caching. The query's author later commented, in another contributor's open PR #13594, that "the similarity query is cacheable" as a design difference from the top-k query, and that top-k kNN queries are not cacheable because deletes invalidate per-segment results (#15379): the same principle, applied to the other family.
• Precedent. LUCENE-8017 (#9065): FunctionRangeQuery and FunctionMatchQuery could "pollute the QueryCache" and were made non-cacheable, which led to the SegmentCacheable contract (LUCENE-8042, #9090). In LUCENE-10060 (#11098) jpountz wrote that the cache keys on the segment core, "everything but live docs and doc-value updates", which "requires cache entries to be computed on the entire segment and follow-up searches to apply deletes on top of cache entries".

The strongest case for "intended" (built by a devil's-advocate verifier, an OpenAI GPT-5.6 reviewer arguing "works as designed" and the adjudication): the author says the query is cacheable by design (#13594); the upstream timeout test knowingly disables the cache; the classes are @lucene.experimental and search "all (approximate) vectors"; Weight#scorer only says live docs "need to be checked on top", which does not forbid a Weight from applying them; and timeouts deliberately allow partial results, so an application could be expected to turn off or partition caching for searches with a timeout.

Why it fails: "cacheable" claims that caching is legal, not that serving one reader's or search's result to another is right, and no javadoc, CHANGES, MIGRATE entry or PR comment accepts that; the test comment covers only the harmless direction and says nothing about live docs or filters; the exact path promises completeness and separate caches give the right answer, so this is cross-reader reuse, not approximation; applying live docs is fine for an uncached Weight, the bug is applying them and also saying true; @lucene.experimental does not permit wrong results. The timeout part is the strongest: no javadoc says setTimeout and the cache must not be combined, and turning the cache off in a test does not accept that later searches reuse a partial result, but a maintainer could prefer documenting it or skipping the cache when a timeout is set (fix B does the latter). The case also misses scoring parents: as a FILTER or MUST_NOT clause the stale set is used too. The GPT-5.6 reviews rated the intended argument weak, and moderate for the timeout part only; the independent reproduction and the intended-behaviour check gave no rating but found none that holds; none could apply it to the live-docs part.

The Weight must stop claiming that a set built from per-reader and per-search inputs is shareable. Two options were built and validated in a scratch worktree at ea57360912ed (removed afterwards); the others are untested or partial.

In AbstractVectorSimilarityQuery's Weight, isCacheable(ctx) returns ctx.reader().getLiveDocs() == null && queryTimeout == null && (filterWeight == null || filterWeight.isCacheable(ctx)). A cached set is then always computed with every document live, no timeout and a segment-immutable filter, so it is the same for every reader sharing the core, and each reader applies its own live docs on top as for any other query. A reader with deletions, a searcher with a timeout or a non-cacheable filter neither reads nor writes the entry. +6/-1, one file.

@Override
public boolean isCacheable(LeafReaderContext ctx) {
  // The per-segment result is computed with the reader's live docs, the searcher's timeout
  // and the filter. The query cache keys entries on the segment core, which ignores
  // deletions and doc-values updates, so only cache a result that depends on none of them.
  return ctx.reader().getLiveDocs() == null
      && queryTimeout == null
      && (filterWeight == null || filterWeight.isCacheable(ctx));
}

Trade-offs

• Segments with deletions never cache this query, and nor does a searcher with a timeout, so NRT indexes with deletes lose part of the caching benefit. No benchmark was run.
• queryTimeout == null is conservative: a timeout that never fires still skips the cache.
• Letting readers with deletions also read an entry filled by a reader without them would be exact for decay 1, but isCacheable governs reading and writing alike, so that needs a change beyond this method.
• Open draft #15802 by the query's author rewrites this Weight (keeping isCacheable); a PR may need to coordinate with it.
• Assumes readers, filters and query parts that keep Lucene's cacheability and core-key contracts, and immutable query state. Main also accepts a caller-supplied KnnSearchStrategy (FloatVectorSimilarityQuery.java:58-64); its Seeded variant holds a DocIdSetIterator that the graph search consumes (KnnSearchStrategy.java:107-171, SeededHnswGraphSearcher.java:37-52). No test covers such strategies or custom reader wrappers.

What the checks validated

• This doc's test: 5 of 5 pass, assertions on and off, through gradle and the harness.
• The 11 nearest upstream suites (Test*VectorSimilarity*, TestLRUQueryCache, TestUsageTrackingFilterCachingPolicy): 139 tests, 0 failures, 8 skipped, assertions on and off.
• The caching probe passes: exact, approximate and filtered queries are still cached and hit on a segment without deletions.
• Every earlier hunt test of this bug, assertions on and off: the finder's 3, the independent reproducer's 9 (Float, Byte, Float16, filtered, timeout, release defaults), the devil's advocate's 9 (controls, soft-deletes view, updated doc-values filter), the security probe's 6 and the GPT-5.6 reviewers' 4 each.
• :lucene:core:check -x test passes (google-java-format, ecjLint, forbiddenApis). tidy completed (its log does not record which files it changed); the final patch and the test pass checkGoogleJavaFormat again in the fact check's re-run.
• The scoring-parent probe (FILTER and MUST_NOT clauses of a scoring query): 4 of 4, assertions on and off.

Replace return true; with return false; and a comment naming the three inputs. +3/-1. The filter query itself is part of the cache key (equals/hashCode, AbstractVectorSimilarityQuery.java:273, :279); its per-reader matches are not. It was validated first by the finder, the independent reproducer, the devil's advocate, the security probe and the GPT-5.6 reviewers, and endorsed by the adjudication, who did not re-run it.

@Override
public boolean isCacheable(LeafReaderContext ctx) {
  // The result depends on the reader's live docs, the searcher's timeout and the filter's
  // per-reader matches, none of which the cache key (query + segment core) captures.
  return false;
}

Trade-offs

The query is never cached, even where that is safe, so every reuse as a filter or count repeats the vector search per segment (an exact scan for decay 1). It contradicts the author's stated intent that the query be cacheable (#13594).

What the checks validated

• This doc's test 5 of 5 and the same 139 upstream tests pass, assertions on and off; :lucene:core:check -x test passes; with the reworded comment, google-java-format, ecjLint and forbiddenApis pass again. The caching probe fails, as expected.
• Re-run on main with the reworded comment, assertions on and off: the finder's 3, the independent reproducer's 9, the security probe's 6, both reviewers' 4 each and the scoring-parent probe's 4 pass. The devil's advocate's 9 give 8: its reverse-direction control first asserts that the query was cached, which this fix rules out (the same expected failure as the caching probe).
• Earlier: 137 upstream tests with the finder's version, and the history probe on main and 9.12.3.

Build the per-segment set without live docs and let collection apply them, as other queries do; still refuse caching with a timeout or a non-cacheable filter.

Trade-offs

Keeps caching on segments with deletions, but changes the approximate path: the graph search already visits and scores rejected nodes and checks the accepted docs only before collecting one (AbstractHnswGraphSearcher.java:98-104, HnswGraphSearcher.java:328-349), so without live docs deleted documents would also be collected and dropped only later, and the filtered path's accepted count and its exact fallback would count them. Needs recall and latency checks.

Asking filterWeight.isCacheable(ctx), or refusing to cache after a timeout, fixes one input and leaves the other two.

Trade-offs

The finder's first alternative left out the filter; a verifier and the adjudication caught it.

Method: code reading (the hunt's non-formal tier).

• A hunt unit (the kNN query layer, 2026-10-25). The finder, an AI tool, compared for each vector query Weight the inputs of its per-segment result with what the LRUQueryCache key contains. AbstractVectorSimilarityQuery's scorerSupplier reads the reader's live docs and the searcher's timeout, while isCacheable returns true.
• Public-API probes and a deterministic JUnit test on the stock jar then showed both the live-docs and the timeout cases.
• A small TLA+ model written afterwards (two readers sharing a core, a timeout flag; invariant Correct) is violated with Cacheable = TRUE and holds with Cacheable = FALSE. It illustrates the mechanism; its files are timestamped after the finding, so it was not the first signal.
• An independent reviewer from another model family (OpenAI GPT-5.6) then tried to refute it; verifiers and an adjudication confirmed it, one of them adding the soft-deletes and doc-values filter triggers; the history, prior-report and security checks followed.