addIndexes(CodecReader...) reports "this IndexWriter is closed" on an open writer during a concurrent deleteAll()

deleteAll() turns merges off, aborts the running merges and waits for them to stop, releasing the writer's lock while it waits. addIndexes(CodecReader...) checks, after its flush, that the writer is open and then that merges are on, and reports "merges off" as AlreadyClosedException("this IndexWriter is closed. Cannot execute addIndexes(CodecReaders...) API"). A call that reaches this check during deleteAll()'s wait therefore says the writer is closed although it is open: isOpen() is true, deleteAll() returns normally and the next call succeeds. deleteAll()'s javadoc names MergeAbortedException for exactly this overlap, and a call whose own merge is already running when the abort comes gets it. A call that hits the check is rejected either way and nothing is lost or damaged, so the defect is the exception type and its false message. It became user-visible in 9.4.0 (LUCENE-10216, #633), which turned assert merges.areEnabled() into this exception; every release 9.4.0 to 10.6.0 and main are affected.

1. The check. addIndexes(CodecReader...) (:3275) flushes (:3286), validates the readers and sums their numDocs() (:3289-3295), calls testReserveDocs (:3296), then in one synchronized block calls ensureOpen() and throws AlreadyClosedException("this IndexWriter is closed. Cannot execute addIndexes(CodecReaders...) API") if merges.areEnabled() is false (:3298-3304).
2. Who turns merges off. merges.disable() has one caller, abortMerges() (:2823), and abortMerges() has two: rollbackInternalNoCommit() (:2621), reached only from close(), rollback() and the tragic-event close, each after shouldClose() has set closing (:1379), so ensureOpen() throws first there; and deleteAll() (:2771), which turns merges back on in a finally block (:2781).
3. The window. abortMerges() marks running merges aborted (:2839-2844) and loops on doWait() while any is still running (:2849-2860). doWait() is wait(1000) (:5860-5872), which releases the writer's monitor, so another thread can enter the check while merges are off.
4. Every hit is on an open writer. Once ensureOpen() has passed, the writer is neither closed nor closing (isOpen() is closing == false && closed == false, :6117-6120), and the only open-writer state with merges off is deleteAll()'s abort wait. The "closed" message is false every time the branch fires.
5. Only this check reports "merges off" as AlreadyClosedException. For regular merges, IndexWriter's private registerMerge throws MergeAbortedException when merges are off (:5165-5167), and updatePendingMerges just finds no merges (:2463-2465). addIndexes(CodecReader...) registers its own merges through AddIndexesMergeSource.registerMerge (:3311, :3408-3417), which has no such check, and throws MergeAbortedException when its own merge was aborted (:3377-3378). So timing decides: a caller whose own merge is already queued or running when deleteAll() aborts gets MergeAbortedException (executed for a running merge); one that reaches the check during the wait gets the false AlreadyClosedException; and, by code reading only, a caller past the check that registers its merge after the abort is not aborted and can succeed.
6. Nothing of the rejected call is kept beyond its normal up-front work (the flush at :3286, which can write buffered documents as a segment, and the reader validation at :3289-3295). The exception comes before findMerges (:3307), before any merge is registered and before reserveDocs (:3356). AlreadyClosedException is an IllegalStateException, not an Error, so the catch (Error tragedy) (:3390-3392) does not run and the writer is not closed.

• Who. Applications that overlap deleteAll() and addIndexes(CodecReader...) on one IndexWriter while some merge is running (with none running, deleteAll() never waits and the check cannot see merges off). Default IndexWriterConfig, ConcurrentMergeScheduler and TieredMergePolicy; no opt-in setting, no scale. IndexWriter is documented as "completely thread safe, meaning multiple threads can call any of its methods, concurrently" (IndexWriter.java:167-168).
• Effect. A call that hits the check is rejected either way (today and with the recommended fix); with the bug the exception type is wrong and its message false. For that call: no data loss, no index damage, no hang. Afterwards the writer keeps working: no tragic exception, deleteAll() removed everything, nothing of the rejected call was added, no leaked document reservation, CheckIndex clean (executed probe). Other overlap positions were not all executed (step 5 of the mechanism).
• Why the type matters. AlreadyClosedException is how IndexWriter reports a writer that is gone, and it is unchecked; MergeAbortedException is an IOException. Code that reacts to AlreadyClosedException by discarding, rolling back or reopening the writer would throw away a healthy writer for a call it could simply retry. Plausible, but not executed anywhere.
• How often without hooks. A stress program built to overlap the calls (3 addIndexes(CodecReader x20) threads, 1 indexing thread, a deleteAll() loop) saw 4 false "closed" exceptions against 95 MergeAbortedExceptions in 252 deleteAll() calls (LogDocMergePolicy), 5 against 110 in 227 and 9 against 107 in 277 (default TieredMergePolicy), and 0 against 17 in a lighter run: numbers from a loaded host, not a general frequency.
• How likely. Rare: it needs this specific overlap, and no user report was found.
• Workaround. Treat AlreadyClosedException from addIndexes(CodecReader...) as fatal only when writer.isOpen() is false, and retry otherwise (a heuristic: the writer can close right after the check); or do not overlap deleteAll() with addIndexes.

A ConcurrentMergeScheduler subclass holds the merge started by forceMerge(1, false) in doMerge until deleteAll() aborts it (OneMerge.getMergeProgress().pauseNanos(...) returns once the merge is aborted); a FilterCodecReader parks the addIndexes caller in numDocs(), which addIndexes reads after its flush and before its check. abortMerges() turns merges off before it aborts the running merge, so the caller is released with merges already off; the merge then waits for the caller to finish, so deleteAll() is still in its wait when the caller enters the check. After that the merge ends and deleteAll() returns normally.

Lint: checkGoogleJavaFormat wraps the 119-character comment above the assertion into two lines; with that change the test lint passes and the test still fails on stock and passes with the fix.

Older releases: the test fails on 9.12.3 and 10.0.0 too. On 9.4.0 and 9.3.0 its merge hook cannot run (pauseNanos there requires the merge thread that IndexWriter assigns later, inside super.doMerge), so it times out; that is a limit of the hook, not a Lucene result, and the finder's longer repro covers 9.4.0.

Regression test: this same test; with the fix it passes with assertions on and off. Its assertion only rules out AlreadyClosedException on an open writer, not which outcome the fix gives; a separate probe of the same scenario saw MergeAbortedException with the fix (-ea and -da).

cp $REPRO/TestAddIndexesDuringDeleteAll.java $LUCENE/lucene/core/src/test/org/apache/lucene/index/
cd $LUCENE && ./gradlew :lucene:core:test --tests TestAddIndexesDuringDeleteAll -Ptests.seed=DEADBEEF
# the same result with -Ptests.asserts=false

# gradle, stock 645d4fe14a20, -Ptests.seed=DEADBEEF, assertions on (the same with -Ptests.asserts=false)
TestAddIndexesDuringDeleteAll > testAddIndexesWhileDeleteAllAbortsMerge FAILED
    java.lang.AssertionError: writer isOpen()=true, but addIndexes threw org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed. Cannot execute addIndexes(CodecReaders...) API
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:7CFAE3F30861324C]:0)
        at org.junit.Assert.fail(Assert.java:89)
        at org.junit.Assert.assertTrue(Assert.java:42)
        at org.junit.Assert.assertFalse(Assert.java:65)
        at org.apache.lucene.index.TestAddIndexesDuringDeleteAll.testAddIndexesWhileDeleteAllAbortsMerge(TestAddIndexesDuringDeleteAll.java:118)
:lucene:core:test (FAILURE): 1 test, 1  failure

# with the fix, assertions on and off
:lucene:core:test (SUCCESS): 1 test

• The javadoc names another exception. deleteAll(): "this method will forcefully abort all merges in progress. If other threads are running forceMerge, addIndexes(CodecReader[]) or forceMergeDeletes methods, they may receive MergePolicy.MergeAbortedExceptions." (IndexWriter.java:2743-2745). The sentence is as old as deleteAll() itself (LUCENE-1705, 2009, then "will receive"; "may receive" since 2011); the check came in 2022.
• The exception's own contract. "This exception is thrown when there is an attempt to access something that has already been closed." (AlreadyClosedException.java:19-22); ensureOpen() throws it "if this IndexWriter is closed or in the process of closing" (IndexWriter.java:905-912). Here ensureOpen() has just passed, in the same synchronized block.
• No other code reports "merges off" as AlreadyClosedException: for regular merges registerMerge throws MergeAbortedException in the same state (:5165-5167), the aborted-merge path of the same method throws it too (:3377-3378), and updatePendingMerges just finds no merges (:2463-2465).
• The authors did not expect an open writer here. Up to 9.3.0 the line was assert merges.areEnabled();, an invariant. In the #633 review the premise for the exception was a closing writer, and deleteAll() is not mentioned in its 52 review comments, 39 reviews and 24 issue comments.
• No test pins it. No upstream test overlaps deleteAll() and addIndexes(CodecReader...) on one writer from two threads; the one test method that calls both does so from a single thread, with addIndexes(Directory...).

The strongest case: the type was chosen on purpose. In the #633 review Michael McCandless (mikemccand) wrote of this check "I think this only happens if IW is aborting/closing? Maybe throw AlreadyClosedException instead? This message is otherwise sort of confusing to the poor user who sees it."; the author, Vigya Sharma (vigyasharma), replied "Changed to AlreadyClosedException.", and Michael McCandless later read it as "this IW is being concurrently closed or aborted (due to unexpected OOME maybe)?". Also, "may receive" is not exclusive, no merge exists yet at the check, and the call is rejected anyway, so it is diagnostics only. (The independent cross-model reviewer, OpenAI GPT-5.6, made this case and rated it strong; a second review rated it moderate.)

Why it fails: the stated premise, "aborting/closing" or "concurrently closed", describes exactly the states ensureOpen() rules out one line earlier; deleteAll()'s abort was not considered. The message says the writer "is closed", which is false every time the branch fires. The exception the javadoc names for this overlap is MergeAbortedException, which a call whose own merge is already queued or running gets; today timing decides whether an overlapping call gets that or the false AlreadyClosedException. And the review's own goal, a message that does not confuse the user, is better met by an exception that names the abort. Verdict: not intended, low severity; the defect and its fix concern only the exception type and message.

One fix was validated in a scratch worktree of 645d4fe14a20; the others are directions, not attempted.

One file, +3/-2 in IndexWriter.java (the finder's change, re-applied to 645d4fe14a20). ensureOpen() already reports a closed or closing writer, so this branch only ever sees deleteAll()'s abort; it now reports what the deleteAll() javadoc names, what registerMerge throws for regular merges in the same state, and what the aborted-merge path of the same method already throws.

       synchronized (this) {
         ensureOpen();
         if (merges.areEnabled() == false) {
-          throw new AlreadyClosedException(
-              "this IndexWriter is closed. Cannot execute addIndexes(CodecReaders...) API");
+          // ensureOpen() passed, so merges are only disabled by a concurrent deleteAll()
+          throw new MergePolicy.MergeAbortedException(
+              "merges are being aborted by deleteAll(); addIndexes(CodecReaders...) was aborted");
         }
       }

Trade-offs

• Same outcome for the caller (the call is rejected, nothing is added); only the type and message change.
• The type alone does not tell a caller whether its merge was aborted or the call was turned away at this check; only the message does.
• MergeAbortedException is a checked IOException; addIndexes already declares IOException and already throws MergeAbortedException (:3378), so no new type reaches callers. Code that caught AlreadyClosedException for this case stops seeing it, which for an open writer is the point.
• Its javadoc says it is thrown "because IndexWriter#abortMerges was called" and is "normally ... privately caught" (MergePolicy.java:573-577); deleteAll() calls abortMerges(), and its javadoc already exposes the exception to these callers.

What the checks validated

• Gradle, scratch worktree of 645d4fe14a20, OpenJDK 25.0.3, 2026-10-31 (worktree removed afterwards): stock, the minimal test fails with assertions on and off; with the fix it passes with assertions on and off.
• Closest suites with the fix: TestAddIndexes (39), TestIndexWriterDelete (27, 6 skipped), TestIndexWriter (119, 1 skipped), TestIndexWriterExceptions (40, 3 skipped), TestIndexWriterMerging (13), TestIndexWriterWithThreads (14): 252 tests, 0 failures, 10 skipped (seed DEADBEEF).
• Lint with the fix and the test's comment wrapped onto two lines (google-java-format rejects the 119-character line): checkGoogleJavaFormat, ecjLintMain, ecjLintTest, forbiddenApisMain and forbiddenApisTest pass; that copy also fails on stock and passes with the fix.
• Earlier, the fix shadowed over the stock jars: the minimal test passes with -ea and -da; an independent reproducer's test 3 of 3 pass; per the second cross-model review, TestAddIndexes 39 of 39 and TestIndexWriterDelete with 0 failures. Not run: nightly tests, other modules.

In the synchronized block, wait while merges are off and re-check ensureOpen() after each wait; the call then runs after deleteAll() and succeeds, which the javadoc's "may" also allows.

Trade-offs

The caller blocks for the whole abort; deleteAll() re-enables merges without a notifyAll() (:2781), so the waiter relies on doWait()'s 1 s timeout unless one is added; and the call's documents then survive the deleteAll(), a semantic choice for the maintainers. Needs its own tests. By code reading, B would hang the minimal test (the held merge waits for the caller, the caller for merges to come back on, deleteAll() for the merge), so it needs a different test and an explicit liveness design.

Say that merges are being aborted by a concurrent deleteAll().

Trade-offs

Removes the false "closed" text but keeps a type that means "closed" for an open writer, so code that reacts to the type is still misled.

Method: formal, with a caveat. The model (AddIndexesMergeSource.tla) covers the merge-source protocol of addIndexes(CodecReader...), deleteAll()'s full-flush lock and abort wait loop, rollback and a running natural merge, with a model-to-Java line map. Configuration da1_ace (1 caller, ConcurrentMergeScheduler, deleteAll(), a natural merge) violated the invariant NoSpuriousACE with a 4-state trace (214 states generated, 120 distinct); da1_fixed (the fix modelled) found no error in 234 distinct states. The invariant names the symptom directly, so the hypothesis may have been formed while writing the model (semi-formal).

The finder replayed the trace as a JUnit with delay-only hooks; independent checks reproduced it with their own tests, and a hook-free stress run showed the window opens without hooks. The minimal test here is a latch-ordered rewrite (no sleeps) with one thread fewer.