Merging an old reader can copy another segment's data after a segment name is reused

In the 10.6 code, released in 10.6.0 on 2026-10-29, the readers for stored fields, raw vectors and compound files can open their data file a second time, by name, when a merge or another sequential read needs it. Nothing checks that the file is still theirs. After a rollback, a later writer can reuse the same segment name, so merging an old reader, for example with addIndexes, copies the other segment's stored fields and vectors, silently when the layouts match (otherwise the merge throws). Since #16883 (2026-10-24) this needs MMapDirectory with read advice such as ADVISE_BY_CONTEXT and files of at least one page.

• Segment: a write-once part of the index, named _0, _1, ... from a counter that is saved only when a commit writes a segments_N file.
• Segment ID: a unique 16-byte value, made fresh for every new segment and stored in the header of each of its files. A reader checks it when it opens a file, so it knows the file belongs to its segment.
• Data files: _0.fdt (stored fields), _0.vec (raw float vectors), _0.cfs (the compound file that packs a small segment's files; on by default).
• Merge instance: the reader a merge reads through (getMergeInstance()). Normal merges, IndexWriter.addIndexes(CodecReader...) and CheckIndex.testStoredFields all use one.

1. New in the 10.6 cycle. A merge reads front to back and a search reads at random, and with memory-mapped files the read-ahead advice applies to a whole mapping. So three PRs made the merge read open the data file a second time, by name, with merge-friendly advice: #16749 for raw vectors (.vec), #16684 for stored fields (.fdt) and #16796 for compound files (.cfs). Up to 10.5.2 the merge read through the input the reader already had open, which had passed the segment-ID check.
2. The second open checks nothing. It does not compare the segment ID. Its only fallback is for a file that is gone; the comment says "an open reader outlives its files, so read through the input it already holds". There is no fallback for a file that was replaced by another file with the same name.
3. A name can be reused while an old reader is open. This part is older, and also true on 10.5.2: writer 1 flushes segment _0 for an NRT reader and ends without a commit, and the reader stays open; writer 2 opens the directory, deletes _0's leftover files (no commit refers to them), raises its counter in memory and ends without a commit, so the raised counter is never saved; writer 3 starts from the saved counter and writes a different segment, also named _0. A flush is enough. On Linux a deleted file stays readable through handles already open, so the old reader still reads its own _0, but the name _0.* now means writer 3's files.
4. Result. addIndexes(oldLeaf) opens _0.fdt / _0.vec / _0.cfs again by name and copies writer 3's stored fields and vectors into the target index. With the same layout (same document count and lengths) it is silent: no exception, CheckIndex on the target is clean at Level.MAX_VALUE, and because terms still come from the old reader, TermQuery(key:old) finds the copied document but it returns writer 3's stored fields. With different layouts the merge throws against a healthy reader, for example IllegalArgumentException: slice() _0.fdt out of bounds; on the merged heads only for a file or inner file of at least a page (the small different-layout cases of the earlier checks, such as an inner .fdt of 458 bytes, no longer throw). The old reader's own searches stay right.

#16883 kept the second open by name and its file-gone-only fallback, but put a condition in front of it: a reader now opens its file again only if the input it holds is not "efficient" for a sequential read (IndexInput#isEfficientFor). On the merged heads the wrong copy needs all of these:

1. an unwrapped mmap input: MMapDirectory (or FSDirectory.open on a 64-bit JVM) on Linux or macOS (only Linux aarch64 was run), not wrapped in a FilterIndexInput;
2. an advice function that gives RANDOM to the reader's open and SEQUENTIAL to the sequential re-read, as MMapDirectory.ADVISE_BY_CONTEXT does for readers not opened by a merge;
3. a data file, or compound inner file, of at least one OS page (4096 bytes here); on main any vector field qualifies, because vector data is page-aligned;
4. the four-step sequence above, with the reader's first sequential read after the name was reused.

With the default advice nothing is opened again, on any directory type and at any size.

• Silent wrong data in 10.6.0 (released 2026-10-29), main and branch_10x. On main, branch_10_6 and branch_10x the committed tests and the shortest test fail, and a plain-Java program copies the wrong document while CheckIndex on the target stays clean. 10.5.2 copies right under the same setting.
• The setting is public and built in. MMapDirectory.ADVISE_BY_CONTEXT is the one built-in function under which #16883's second open does anything, and #16883's own tests use it. So every user the optimization helps runs the unchecked open. "A page" is 4 KiB, so any segment with more than about 4 KiB of stored fields qualifies, and on main every vector field.
• A second public path. KnnVectorsReader#getFloatVectorValues(field, DataAccessHint.SEQUENTIAL), new in #16883, returned writer 3's vector on the stale reader, outside any merge. No Lucene caller passes SEQUENTIAL yet.
• What makes it rare. It needs that non-default advice and an unusual sequence: an NRT reader kept open across two writer sessions that end without a commit (rollback(), or close() with setCommitOnClose(false)), then a merge of that reader. No Lucene production code sets ADVISE_BY_CONTEXT. The call itself is real: Solr's SolrIndexSplitter calls addIndexes on wrapped leaves of a live searcher.
• Downstream (read from code, not run, low confidence). Neither Elasticsearch nor OpenSearch built on a Lucene with #16883 as of 2026-10-24. Elasticsearch wraps every input in a FilterIndexInput subclass, so its shards would not reach the re-open; OpenSearch sets ADVISE_BY_CONTEXT for hybridfs (its default on 64-bit) and mmapfs and does not wrap inputs, so it would reach the re-open once it moves to such a Lucene. No code read here merges a reader that outlived its files.
• Before 24 October it needed no setting at all: on the pre-#16883 heads the default configuration copied the wrong data with every directory type tested (FSDirectory.open, which is MMapDirectory here, NIOFSDirectory and ByteBuffersDirectory).
• Platforms. On-disk directories on Windows cannot hit it, because an open file cannot be deleted (not run on real Windows); NIOFSDirectory and ByteBuffersDirectory no longer reach it on the merged heads.

# Lucene main 645d4fe14a20, assertions on (-ea), seed DEADBEEF: 1 test(s) run, 1 failed
    => org.junit.ComparisonFailure: expected:<[old]> but was:<[new]>
       org.junit.Assert.assertEquals(Assert.java:117)
       org.junit.Assert.assertEquals(Assert.java:146)
       org.apache.lucene.index.TestMergeInstanceReopenByName.testAddIndexesCopiesTheReadersOwnStoredFields(TestMergeInstanceReopenByName.java:35)

• Readers that outlive their writer are documented as usable. The NRT javadoc on DirectoryReader.openIfChanged(DirectoryReader, IndexWriter) says "Once the writer is closed, any outstanding readers may continue to be used." rollback() is a close ("Close the IndexWriter without committing ..."), and close() with setCommitOnClose(false) calls rollback().
• Writer 2 deleting the leftovers is the designed path. StandardDirectoryReader.doClose: "our original writer was closed before we were ... The next time IW is opened on the index, it will delete them."
• The contracts promise the reader's own data. addIndexes(CodecReader...): "Merges the provided indexes into this index." StoredFieldsReader.getMergeInstance(): "Returns an instance optimized for merging."
• The 10.6 code itself means to read the reader's own data after its files are gone: the fallback comment, #16796's PR body ("If the compound file is gone, merge opens fall back to the reader's mapping.") and a dedicated test, TestLucene90CompoundFormat.testFallBackToTheReaderMappingWhenTheFileIsGone. Only "file replaced" was missed.
• Lucene already knows names get reused and guards against it elsewhere. ReplicaNode.fileIsIdentical compares header (segment ID included) and footer, with the comment "Segment name was reused! This is rare but possible and otherwise devastating". StandardDirectoryReader compares segment IDs before it reuses an old SegmentReader of the same name, and throws an IllegalStateException on a mismatch.
• Every release tested handles the same sequence correctly: the name is reused, but the copy is right (8.11.4 to 10.5.2; 10.5.2 also under ADVISE_BY_CONTEXT).

The intended-behaviour checker found no doc, javadoc, CHANGES entry, PR discussion or SECURITY.md clause that makes this sequence unsupported. Verdict: a bug, not intended. The strongest counter-argument is about where to put the blame: the file-format docs promise "File names are never re-used. That is, when any file is saved to the Directory it is given a never before used filename." (lucene104/package-info.java:202). A committer can argue that the 10.6 re-open is correct under that rule, and that the real defect is the older name reuse after rollback (the study's finding L).

The answer: Lucene itself breaks the rule through public API calls; its own replicator says reuse happens and guards against it with the same kind of check as the proposed fix; 10.5.2 survives the reuse, and the 10.6 re-open is the first code that turns it into wrong data. Suggested framing: one issue about the wrong copy that names the name reuse as its precondition. Not a security issue: SECURITY.md puts it out of scope (the trigger is the application's own call sequence), so a public issue is fine.

The checks validated an identity check after each re-open; the other options come from the brief's list for the PR author.

A new CodecUtil.reopenedIfSameFile(IndexInput reopened, IndexInput original) (public static, @lucene.internal): if the lengths are equal and the full index headers are byte-equal (codec name, version, 16-byte segment ID, suffix) it returns reopened; otherwise it closes reopened and returns original, the reader's validated input, as 10.5.2 did. Each of the three sites wraps its existing directory.openInput(...) in it; the file-gone fallback is unchanged.

For the merged code use the port on local branch r106-merge-instance-reopen-by-name-pr16883-test (9d6362a4a2): 4 files, CodecUtil +30, the compound reader and the stored-fields and flat-vectors readers.

Trade-offs

• It adds a public @lucene.internal method to CodecUtil during the feature freeze; the alternative is three private copies of the helper.
• Cost: it reads 46 bytes (.cfs), 54 bytes (.fdt) or about 82 bytes (.vec) of header from both inputs, once per reader and file on the merged code (after a mismatch the ported compound reader keeps no copy, so a later conflicting open of an inner file checks again, only in this rare case).
• On a mismatch the reader keeps its random-advice input for later sequential reads (only in this rare case).
• It does not apply as is to branch_10_6 or branch_10x: two catch lines differ, so a backport needs them adapted by hand; not built or run there.
• Style: it uses a boolean ... try/finally pattern that open PR #16888 is removing from these readers; #16571 edits CodecUtil in another hunk.
• Not tested: a direct unit test of the helper, files with different layouts but the same length, Faiss. It does not fix the name reuse itself.

What the checks validated

• On merged main ea57360912 the port applies cleanly and, with the v3 class, both probes, TestStoredFieldsMergeReadAdvice, TestVectorsMergeReadAdvice, TestLucene90CompoundFormat, TestMMapDirectory and TestCodecUtil, gives 167 tests and 0 failures (:lucene:core:check not run on it).
• On the #16883 PR head it kept #16883's own tests green.
• The older fix commits (pre-#16883 code): 56 tests in 4 classes; 76 tests in 5 classes on main; reverting any one file makes exactly that site's test fail; org.apache.lucene.codecs.* plus 12 index classes, 1,756 tests, 0 failures; every plain-Java harness copies right, quantized HNSW included.

Use checkIndexHeader with the reader's segment ID and suffix instead of comparing bytes with the original input. ReplicaNode.fileIsIdentical is Lucene's own precedent for an identity check by header and footer.

Trade-offs

Each site needs the expected ID and suffix at hand; otherwise the same cost as the byte comparison.

Open it while the name still identifies the reader's file.

Trade-offs

A second mapping per reader whenever the advice conflicts, which #16883 moved away from (it opens lazily).

Revert the optimization.

Trade-offs

The largest change, and it undoes most of #16883.

Persist or skip the counter so a rolled-back segment's name is never handed out again, which restores the documented "File names are never re-used" rule.

Trade-offs

Not a 10.6-sized change, and it does not cover wipe-and-rebuild under an open reader. A good follow-up either way.

Method: randomized model-based testing (the study's run-1 testing baseline, "non-formal"; not a formal-methods find).

• On 2026-10-22 an AI tool wrote a harness of about 2,400 lines that runs random sequences of IndexWriter and NRT operations, single-threaded (SerialMergeScheduler), against a reference model, with CheckIndex and checkReader checks, on main 7cecf79523 (which already had #16684, #16749, #16769, #16796 and #16622, but not #16883).
• In its first full 15-minute hunt (seed DEADBEEF), TestUtil.checkReader on an old NRT reader failed with a CorruptIndexException twice: at 67 s on a compound segment, and at 161 s (Corrupted: docID=0, docBase=0, chunkDocs=12, numDocs=1 ... file=_9.fdt). The shrinker cut the second to 9 operations, including two ROLLBACKs and a CHECK_READER of the old reader, and no commit.
• The AI tool then wrote a deterministic JUnit repro and traced it to mergeFieldsStream() (#16684). The task text listed rollback and addIndexes(CodecReader...) among the operations; running checkReader on old NRT readers, which is what fired, was the AI tool's own choice. Nothing in the task mentioned merge instances, re-opening files or name reuse.
• Separate AI verifiers reproduced it with their own tests and found the vectors and compound sites by reading the code; the 2026-10-23 checkers found the quantized-format extension (#16622) by running it.
• The P model reached it only after its task text listed the testing baseline's bug classes and it added an explicit "merge instance re-opens by name" flag: the bug re-encoded, not found. TLA+, Alloy and the JBMC slice could not express it.

That hunt ran on pre-#16883 code with the default advice; on today's heads the same harness would need ADVISE_BY_CONTEXT and larger values to see it (inferred, not run).