With an index sort, a failure while creating the sorted stored-fields or term-vectors writer during flush leaves the temporary files open after IndexWriter closes itself

With IndexWriterConfig#setIndexSort, a segment's stored fields (and term vectors) are first written in arrival order to temporary files. At flush, SortingStoredFieldsConsumer.flush opens a reader on those files, then creates the final sorted writer, and only then enters the try whose finally closes both. If creating the final writer throws, for example because the .fdm file cannot be created when the process has too many open files, the finally never runs and the reader, a local variable, is lost. The flush failure is aborting, so IndexWriter closes itself as designed and abort() deletes the temporary files by name, but nothing closes the 2 inputs on them. SortingTermVectorsConsumer.flush has the same order. A one-document test shows 2 handles still open after close(); on MMapDirectory, the 64-bit default, the 2 deleted files stay mapped after Directory.close() and System.gc(), so their disk space stays allocated. The order dates from LUCENE-7579 (2016): every release from 6.5.0 to 10.6.0 and main is affected. Moving the writer creation into the existing try fixes it.

• Index sort: IndexWriterConfig#setIndexSort, an opt-in setting that keeps the documents of every segment in sort order.
• Temporary files: while documents are buffered, SortingStoredFieldsConsumer writes their stored fields uncompressed to temporary files (_0.fdt__1.tmp, _0.fdx__4.tmp) through a TrackingTmpOutputDirectoryWrapper; SortingTermVectorsConsumer does the same for term vectors (.tvd/.tvx).
• Tragic close: any exception during a flush is aborting; the in-memory segment is discarded and IndexWriter closes itself.

1. With an index sort the indexing chain uses the two sorting consumers (IndexingChain.java:152, :154).
2. At flush (IndexingChain.java:345), SortingStoredFieldsConsumer.flush opens the temporary reader (SortingStoredFieldsConsumer.java:111-113; it keeps 2 inputs open), then creates the final writer (:116-117), then enters the try (:118) whose finally runs IOUtils.close(reader, sortWriter) (:136) and deletes the temporary files (:137).
3. The final writer's constructor creates .fdm and .fdt, two temporary outputs of FieldsIndexWriter, and writes codec headers (Lucene90CompressingStoredFieldsWriter.java:129-162). All of that is inside its own try: when any of it throws, the constructor closes its own outputs (:160) and rethrows; the statements before that block (such as compressionMode.newCompressor(), :120) create no file. The exception leaves flush before the try, so the finally never runs and the reader local is dropped.
4. DocumentsWriterPerThread.flush treats the exception as aborting (DocumentsWriterPerThread.java:585-589) and fires the tragic event (:602): IndexWriter closes itself. SortingStoredFieldsConsumer.abort (:142-151) deletes the temporary files by name; it has no reference to the reader. The 2 inputs now point at deleted files that nothing will close.
5. SortingTermVectorsConsumer.flush has the same order: reader :62-64, writer :68-71, try :72, finally :80; abort :97-104.
6. On MMapDirectory the inputs are mapped in a shared arena (MMapDirectory.java:329, :402-429; RefCountedSharedArena.java:74) that only closing every input releases, so garbage collection and Directory.close() leave the mapping in place.

One document, the default codec, createOutput of _0.fdm failing once: commit() throws, close(), and MockDirectoryWrapper counts 2 open files, {_0.fdx__4.tmp=1, _0.fdt__1.tmp=1}, the unclosed input opened at SortingStoredFieldsConsumer.flush(SortingStoredFieldsConsumer.java:112). On a real MMapDirectory both deleted files are still listed in /proc/self/maps after the tragic close, after 5 calls to System.gc() and after Directory.close(); on NIOFSDirectory, /proc/self/fd lists both until a System.gc() releases them.

• Who is exposed. Applications that set IndexWriterConfig#setIndexSort (opt-in). No scale is needed: one document is enough. Since 8.7.0 every sorted flush opens the temporary stored-fields reader (by code reading, not executed: before the flush StoredFieldsConsumer.finish, StoredFieldsConsumer.java:97-102, called at IndexingChain.java:344, starts every document not yet started, and starting a document creates the temporary writer, :55-57, even when no document has a stored field; the hasStoredFields check at SortingStoredFieldsConsumer.java:129 only skips the per-document reads); the term-vectors reader only when term vectors exist.
• What it takes. A failure to create or open a file while the flush constructs the final stored-fields or term-vectors writer: too many open files (EMFILE/ENFILE), a permission, quota or inode limit, a read-only remount, or a Directory or codec that throws.
• Not disk full, normally. On an FSDirectory the constructor's header writes go into an 8 KiB buffer (FSDirectory.java:378, :400; OutputStreamIndexOutput.java:48), so an out-of-space error usually surfaces later, inside the try, where the reader is closed. Running out of inodes or quota can fail the file creation itself (listed above).
• How often, given such failures. Under upstream's own untargeted open-failure model (MockDirectoryWrapper#setRandomIOExceptionRateOnOpen(0.1) during commit, 300 rounds per arm), 28 of 300 index-sorted rounds leaked (23 the .fdt/.fdx pair, 5 the .tvd/.tvx pair), 0 of 300 unsorted rounds and 0 of 300 with the fix. (The history step's version-portable port, a different harness, counted 56 of 300 on the same commit; the two counts are not comparable.) The failure itself is rare, and nobody has reported the leak since 2017.
• What happens. Per failed flush, 2 inputs on deleted temporary files stay open (on main and from 8.6.3 on; on 6.5.0 to 7.7.3 one per consumer). On MMapDirectory (the 64-bit default) they are 2 mappings that survive IndexWriter.close(), Directory.close() and System.gc(); while they live, the disk space of those files stays allocated: the uncompressed stored fields (or term vectors) of the one segment that failed to flush. On NIOFSDirectory they are 2 file descriptors, released by System.gc() in one run. The application cannot release them: no API reaches the reader. Process exit does; whether anything earlier does was not tested.
• What does not happen. No hang, no wrong results, no corruption. The failed segment is discarded by the tragic close, as designed; the last commit stays intact and a new IndexWriter opens it normally. A later writer on the same MMapDirectory does not keep later segments' files mapped (its segments were _1 to _3; MMapDirectory groups mappings by segment name, so whether a later segment again named _0 would stay mapped was not tested). Windows, where open files cannot be deleted, was not tested.

In a sorted flush only the final sorted stored-fields writer creates the .fdm file (the temporary writer goes through createTempOutput), so failing that one name hits exactly the window. The default codec is pinned so the extension is fixed. Term vectors share the root cause and the fix and were reproduced separately by the finder, the independent reproduction, a separate test and the adjudication.

With one document the test needs 8.7.0 or later (before LUCENE-9510 an already-sorted flush renamed the temporary files and opened no reader), and its org.apache.lucene.tests.* imports need 9.1.0 or later; older releases were checked with a version-portable main() port that indexes 3 documents in reverse sort order.

As the regression test: the same test, for example as a new method in TestSortingStoredFieldsConsumer, which already wraps its directory in a FilterDirectory.

cp TestSortedFlushTempReaderLeak.java $LUCENE/lucene/core/src/test/org/apache/lucene/index/
cd $LUCENE && ./gradlew :lucene:core:test --tests org.apache.lucene.index.TestSortedFlushTempReaderLeak -Ptests.seed=DEADBEEF
# add -Ptests.asserts=true or -Ptests.asserts=false to force assertions on or off: same result

# gradle, main 645d4fe14a20, seed DEADBEEF, -Ptests.asserts=true (verbatim excerpt); the same with -Ptests.asserts=false
TestSortedFlushTempReaderLeak > testFailedSortedStoredFieldsWriterLeavesTempReaderOpen FAILED
    java.lang.AssertionError: open file handles after IndexWriter closed expected:<0> but was:<2>
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:FE21DBF8CE31E49D]: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.apache.lucene.index.TestSortedFlushTempReaderLeak.testFailedSortedStoredFieldsWriterLeavesTempReaderOpen(TestSortedFlushTempReaderLeak.java:59)

# the same test calling MockDirectoryWrapper.close() instead of the assertion (standalone, -ea; excerpt, the frames in between left out)
java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are still 2 open files: {_0.fdx__4.tmp=1, _0.fdt__1.tmp=1}
Caused by: java.lang.RuntimeException: unclosed IndexInput: _0.fdx__4.tmp
	...
	at org.apache.lucene.codecs.lucene90.compressing.Lucene90CompressingStoredFieldsReader.<init>(Lucene90CompressingStoredFieldsReader.java:206)
	at org.apache.lucene.codecs.lucene90.compressing.Lucene90CompressingStoredFieldsFormat.fieldsReader(Lucene90CompressingStoredFieldsFormat.java:133)
	at org.apache.lucene.index.SortingStoredFieldsConsumer.flush(SortingStoredFieldsConsumer.java:112)
	at org.apache.lucene.index.IndexingChain.flush(IndexingChain.java:345)
	at org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:492)

• The contract. IndexWriter.close(): "Closes all open resources and releases the write lock." (IndexWriter.java:1342). The class javadoc: "if you hit an Error, or disaster strikes during a checkpoint then IndexWriter will close itself" (:162-165); nothing says it may then leave files open. This states the intent, not a promise for the tragic path: the writer has already closed itself (IndexWriter.java:6094, :6098-6105), and a later close() does nothing (shutdown and shouldClose, :1319, :1374-1393).
• The code's own intent. The finally at SortingStoredFieldsConsumer.java:136 closes the reader and the writer together on every path through the try; only the writer's creation was left one statement outside. No comment, commit or PR explains the order, and the fix keeps it.
• Cleanup after exceptions was designed here. In the LUCENE-7579 review (#8630), mikemccand asked whether an IOException "during the renaming that SortingStoredFieldsConsumer.flush does" (a rename step of that time) could "leave undeleted files"; jimczi added abort() to both consumers in answer. IndexingChain.abort's comment says its finalizer "will e.g. close any open files in the term vectors writer" (IndexingChain.java:531): the abort path closes the files it owns, but nothing on it owns the temporary reader, a local variable of flush. The bug is that ownership gap.
• Lucene's tests enforce it. MockDirectoryWrapper.close() throws "cannot close: there are still N open files" with no exemption for a tragic close (MockDirectoryWrapper.java:873-887); TestIndexWriterOutOfFileDescriptors accepts a tragic close (:88) and then calls dir.close() (:166). No upstream test combines setIndexSort with failure injection: a coverage gap, consistent with CI never having caught this.
• Upstream fixes the same pattern as a bug. Two fixes move a create or open call that sat before its try into it: #14394 (9b9fbd44339, 2025: two createTempOutput calls, declared null and assigned inside the try) and d16e25518ba (2026: "the open call was outside the relevant try-catch block"). #12739 (361f0a4524d, 2023) is the same family, not the same shape: it adds a temporary output that was missing from the failure-path close list.
• The trigger is legal. Directory#createOutput declares IOException (Directory.java:90-92), and MockDirectoryWrapper#setRandomIOExceptionRateOnOpen is upstream's own model of running out of file descriptors.

Argument: the flush has already failed and the writer is tragically closed, so its state afterwards is best effort; the trigger is an environmental failure in a one-statement window; and the order could be deliberate.

Why it fails: close() is documented to close all open resources, abort() was added precisely to clean up after this kind of exception, Lucene's test framework fails any test that leaves a file open after a tragic close, and every other tragic flush failure the verifiers tried released all handles (the controls, and 0 of 300 unsorted rounds). Nothing documents or explains the order. The leaked inputs are also beyond the application's reach: no API returns them, and on MMapDirectory not even Directory.close() releases them. What the argument does limit is the impact: a minor leak on a rare error path.

Two options were run through gradle in a scratch worktree of 645d4fe14a20; both change only SortingStoredFieldsConsumer.flush and SortingTermVectorsConsumer.flush. A is the smallest change and keeps the existing finally.

Declare the writer as null before the try and assign it as the first statement inside, in both consumers: 10 lines added, 6 removed (formatted by google-java-format). The existing finally then runs IOUtils.close(reader, sortWriter), which ignores a null writer, and deletes the temporary files.

-    StoredFieldsWriter sortWriter =
-        codec.storedFieldsFormat().fieldsWriter(state.directory, state.segmentInfo, state.context);
+    StoredFieldsWriter sortWriter = null;
     try {
+      sortWriter =
+          codec
+              .storedFieldsFormat()
+              .fieldsWriter(state.directory, state.segmentInfo, state.context);

// SortingTermVectorsConsumer.flush: the same move for `TermVectorsWriter writer`

Trade-offs

• Smallest change, in the same shape upstream used for #14394 (declare null, assign inside the try); the order (reader, then writer) and the finally stay as they are, so the success path is unchanged. It covers exactly the window: if super.flush or the reader's constructor throws, nothing changes.
• IOUtils.close ignores null arguments (its javadoc: "Some of the Closeables may be null; they are ignored."), so no extra check is needed.
• It keeps one existing quirk and extends it to the writer's creation: if closing throws in the finally, that exception replaces the one from the try body, so a failure to close the reader would now also hide the writer-creation exception. Option B would change that.

What the checks validated

• Gradle on 645d4fe14a20, seed DEADBEEF: without a fix the repro fails with assertions on and off and the finder's 3-test class fails 4 of 4 (3 tests and the suite-level leaked-file-handle check).
• With fix A: the repro passes with assertions on and off; in one run with assertions on, the repro, the finder's 3 tests and the closest upstream suites (TestIndexSorting 62, TestIndexWriterExceptions 40, TestIndexWriterOnDiskFull 4, TestIndexWriterOutOfFileDescriptors 1, TestSortingCodecReader 3, TestSortingStoredFieldsConsumer 1, TestTrackingTmpOutputDirectoryWrapper 2) give 9 classes, 117 tests, 0 failures, 3 skipped (the three @Nightly tests of TestIndexWriterExceptions).
• With fix A the repro also passes with assertions off.
• Format: written as a plain move, the stored-fields line goes over 100 columns and checkGoogleJavaFormat fails on it alone (the repro test itself is clean); applyGoogleJavaFormat wraps that line, and with the formatted diff the check passes and the repro and the finder's 3 tests pass again (4 of 4). The suites ran with the unformatted diff, which differs only in line breaks.
• Earlier, by the study: the same change passes every focused repro, upstream's random open-failure model (0 of 300 rounds) and the MMapDirectory probe (no mapping left), and the same move on the 6.5.0 sources fixes 6.5.0. The full Lucene test suite was not run.

Make both the reader and the writer resources of one try (...) and drop IOUtils.close(reader, writer) from the finally, which keeps only the deletion of the temporary files: 19 lines added, 21 removed, google-java-format clean as written.

-    StoredFieldsReader reader =
-        TEMP_STORED_FIELDS_FORMAT.fieldsReader(
-            tmpDirectory, state.segmentInfo, state.fieldInfos, IOContext.DEFAULT);
-    StoredFieldsWriter sortWriter =
-        codec.storedFieldsFormat().fieldsWriter(state.directory, state.segmentInfo, state.context);
-    try {
+    try (StoredFieldsReader reader =
+            TEMP_STORED_FIELDS_FORMAT.fieldsReader(
+                tmpDirectory, state.segmentInfo, state.fieldInfos, IOContext.DEFAULT);
+        StoredFieldsWriter sortWriter =
+            codec.storedFieldsFormat().fieldsWriter(...)) {
       ...
     } finally {
-      IOUtils.close(reader, sortWriter);
       IOUtils.deleteFiles(tmpDirectory, tmpDirectory.getTemporaryFiles().values());

// SortingTermVectorsConsumer.flush: the same, see the diff file

Trade-offs

• The idiomatic Java form; a resource that was opened is always closed, whatever throws.
• Small behaviour changes: resources close in reverse order (writer, then reader); an exception from the body is kept and close failures are added to it as suppressed (today a close failure in the finally replaces it); and when opening the reader itself fails, the finally now deletes the temporary files (today only abort() does).
• Larger diff: the declarations move into the try header, and the long writer expression is re-wrapped.

What the checks validated

• Gradle on 645d4fe14a20, seed DEADBEEF, same worktree: the repro passes with assertions on and off; the same suites run as for fix A gives 9 classes, 117 tests, 0 failures, 3 skipped; checkGoogleJavaFormat passes.

Method: semi-formal (exception-point enumeration of the real jar against a model). On 2026-10-26 a hunt unit ran short scripts of document-level IndexWriter operations (add, update, delete, batches, commits, near-real-time readers) under several configurations, one with an index sort. For every operation it enumerated each distinct MockDirectoryWrapper failure site, made it throw one IOException in turn, and classified the outcome against a model as unchanged, applied or tragic; then it checked MockDirectoryWrapper.close() for open files. In its exhaustive 2-operation runs (3 runs, about 14.4 million executions), the injections at createOutput, createTempOutput and the header writes inside the constructor of the sorted stored-fields or term-vectors writer were classified tragic, as expected, and then failed the open-file check (cannot close: there are still 2 open files: {_1.fdt__f.tmp=1, _1.fdx__m.tmp=1}). The root cause was then read from the code and a targeted JUnit written; it was later cut to the one-test repro. It could also be read as model-based randomized testing.