TaskExecutor#invokeAll returns while a task is still running when the calling thread is interrupted

TaskExecutor#invokeAll runs some tasks on the executor and the rest on the calling thread, then waits for each future in turn. If the calling thread is interrupted while it waits, Future.get() throws InterruptedException; collectResults records it as a ThreadInterruptedException and moves on to the next future, but never waits for that one again. So invokeAll ends while the task is still running, against its javadoc ("wait for them to complete"), a code comment ("invokeAll does not leave any running tasks behind when it returns") and its own assertion, which fires with -ea. With -da the call throws ThreadInterruptedException; through IndexSearcher#search a slice keeps collecting after search has thrown, its exception is lost, and if the caller closes the reader while the slice still reads it, the slice fails with an AlreadyClosedException that is never reported. It needs concurrent search with an executor and an application that interrupts the searching thread. Present in this form since 9.9.0, when #12523 made invokeAll wait for all tasks on failure but left the interrupt path behind; every release through 10.6.0 and main.

// invokeAll: count - 1 workers go to the executor, the caller runs tasks until none is left (:91-114)
return collectResults(futures);                                          // :115

for (Future<T> future : futures) {                                      // collectResults, :121
  try {
    results.add(future.get());                                           // :123
  } catch (InterruptedException e) {
    exc = IOUtils.useOrSuppress(exc, new ThreadInterruptedException(e)); // :124-125, then the next future
  } catch (ExecutionException e) {
    exc = IOUtils.useOrSuppress(exc, e.getCause());                      // :126-127
  }
}
assert assertAllFuturesCompleted(futures) : "Some tasks are still running?";   // :130
if (exc != null) { throw IOUtils.rethrowAlways(exc); }                   // :131-133

• Every task is claimed before the wait. The caller keeps claiming task ids until none is left (:107-114), so in collectResults a future that is not done has been claimed by another thread, which is running it or about to start it.
• Only the interrupted future is abandoned (one per interrupt). FutureTask.get() on a task that is still not done checks and clears the interrupt flag and throws. The loop records it and calls get() on the next future, which now blocks normally. An independent test with 3 tasks shows it: after the interrupt invokeAll kept waiting while both pool tasks were blocked, and returned as soon as task 2 was released, with task 0 still blocked ("done at return: [false, true, true]"). A second interrupt during a later wait would abandon a second future.
• Outcome. -ea: the assertion at :130 fails. -da: :131-133 rethrow ThreadInterruptedException. The abandoned task's value or exception is never read.
• Through IndexSearcher. search(Query, CollectorManager) runs one task per slice through taskExecutor.invokeAll(listTasks) (IndexSearcher.java:778-789). The throw skips reduce; the abandoned slice keeps collecting and reading the reader.
• Not without an executor. new IndexSearcher(reader) uses new TaskExecutor(Runnable::run) (IndexSearcher.java:223): every task runs on the calling thread before the wait, so nothing is left running.

• Who. TaskExecutor with a real executor, in practice new IndexSearcher(reader, executor) (opt-in, @lucene.experimental) with 2 or more slices, plus an application that interrupts the thread that called search. Other invokeAll callers, by reading only: kNN query rewrite (AbstractKnnVectorQuery), match highlighting (MatchRegionRetriever), the sandbox PostCollectionFaceting, the concurrent HNSW merge (HnswConcurrentMergeBuilder), and BP index reordering in lucene/misc (BPIndexReorderer).
• With assertions on (test suites, CI): an AssertionError from inside Lucene instead of the ThreadInterruptedException the code means to throw.
• With assertions off (production): the call throws while a slice still runs. That slice's exception is never reported to the caller, the slice may keep running (and using CPU, read from the code, not measured) after the request was cancelled, and if the caller closes the reader while the slice still reads it, the slice fails with an AlreadyClosedException that is never reported (observed with ByteBuffersDirectory; MMapDirectory and NIOFSDirectory not tested). No wrong result is returned, because the call throws.
• Scale. Any index with 2 or more slices and one interrupt that reaches get() while that task is still not done; it reproduced in every controlled iteration (20 of 20 and 10 of 10).
• Likelihood: rare. A Lucene committer said Lucene will not support interrupting long-running queries ("not going to support Thread.interrupt or any nonsense like that. you already have the exitable reader: use that", #12023), and the IndexSearcher javadoc warns that shutdownNow interrupts can close NIOFSDirectory file descriptors. No report was found.

The class sits in org.apache.lucene.search next to TestTaskExecutor and uses only TaskExecutor(Executor) and invokeAll. Concurrency is the bug, so it needs one executor thread, but the order is fixed by a Semaphore and a latch, without sleeps: the executor starts a new thread per execute() and returns only once that thread's task has started, so the executor thread always runs task 0 and the calling thread runs task 1, the last one. Task 1 sets the calling thread's interrupt flag, standing for a cancellation interrupt that lands while the caller runs its own share; the independent test shows the same with a real Future.cancel(true) from another thread. Task 0's 10 s bound only lets a correct invokeAll, which keeps waiting for it, end.

The test applies to 9.12.0 and later, where the caller runs the last task itself; before 9.12.0 a port was used (run on 9.8.0, 9.9.0 and 9.11.1).

Regression test: this same class (or its one method in TestTaskExecutor); with the recommended fix it passes in about 10 s, the length of task 0's bound.

cp $REPRO/TestTaskExecutorInterruptedCaller.java $LUCENE/lucene/core/src/test/org/apache/lucene/search/
cd $LUCENE && ./gradlew :lucene:core:test --tests org.apache.lucene.search.TestTaskExecutorInterruptedCaller -Ptests.seed=DEADBEEF
# assertions off fails too, with the other message: add -Ptests.asserts=false (the recorded runs added --offline --no-daemon)

# gradle, stock 645d4fe14a20, -Ptests.seed=DEADBEEF (stack trimmed)
TestTaskExecutorInterruptedCaller > testInvokeAllWaitsForRunningTaskWhenCallerIsInterrupted FAILED
    java.lang.AssertionError: expected invokeAll to wait for task 0, but it ended with java.lang.AssertionError: Some tasks are still running? while task 0 was still running
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:B96B8E1E2B8E23BD]:0)
        at org.apache.lucene.search.TestTaskExecutorInterruptedCaller.testInvokeAllWaitsForRunningTaskWhenCallerIsInterrupted(TestTaskExecutorInterruptedCaller.java:51)
:lucene:core:test (FAILURE): 1 test, 1  failure

# the same with -Ptests.asserts=false
    java.lang.AssertionError: expected invokeAll to wait for task 0, but it ended with org.apache.lucene.util.ThreadInterruptedException: java.lang.InterruptedException while task 0 was still running

# standalone runner: main fails with -ea and -da (20 of 20 derived seeds with -da); 10.5.2 (-ea, -da), 10.6.0 and 9.12.3 (-ea) fail the same way

• The class states the opposite. Class javadoc: "then waits for all tasks that have been executed in parallel on the executor to be completed and then returns" (TaskExecutor.java:41-43). invokeAll: "wait for them to complete and return the obtained results" (:71). Task#cancel comment: "We rather want to make sure that invokeAll does not leave any running tasks behind when it returns." (:185-186). The assertion: assertAllFuturesCompleted(futures) : "Some tasks are still running?" (:130).
• History. #12523 (2023, first in 9.9.0): "This commit ensures that it instead waits for all tasks to complete before it re-throws the exception." It turned throw new ThreadInterruptedException(e) into record-and-continue, without waiting for the interrupted future again. #12689 (2023, 9.9.0) added the assertion and the comment. None of the PR threads that shaped the class (#12523, #12689, #13472, #13609, #13622, #13861) mentions interrupts.
• The expectation upstream. #12278 (open): "Is it a reasonable expectation that once IndexSearcher#search(Query, CollectorManager) returns, that specific search has completed and has left no threads behind still working on it? I would expect this to be true". It is about task exceptions, not interrupts.
• Tests. TestTaskExecutor has 10 tests; none mentions interrupts.
• Not a coherent alternative. After the interrupt the loop still waits for every other running task and abandons only the one it was blocked on (executed).
• A legal, anticipated trigger. Lucene's javadoc addresses "Applications using Thread#interrupt() or Future#cancel(boolean)" (FSDirectory.java:65-67, :77-82; NIOFSDirectory.java:41-46), and IndexWriter documents its own interrupt handling (IndexWriter.java:172-175).

The strongest case for "intended" (a read-only cross-model review and the tie-break): Lucene does not support Thread#interrupt as cancellation (#12023), TaskExecutor is @lucene.experimental, and the JDK's own ExecutorService#invokeAll returns at once when interrupted, so an interrupted caller cannot expect the wait-for-all guarantee.

Why it fails: #12023 rejects making Lucene stop its work on interrupt; this report asks only that the existing interrupt handling keeps the invariant the class states, comments and asserts. @lucene.experimental marks API instability, not a licence to break a stated invariant. The JDK cancels the remaining tasks with cancel(true) before it returns (cooperatively, so a task that ignores interrupts can outlive its invokeAll too, but every task is asked to stop); Lucene's Task#cancel rejects that (assert mayInterruptIfRunning == false : "cancelling tasks that are running is not supported", :183), and today's code does wait for the other tasks, so it follows neither policy. The reviewers' one request, a genuine interrupt from another thread with standard pools and a control, was executed and fails the same way. Still, whether invokeAll should wait for all tasks or return at once after an interrupt is a policy choice for maintainers, not an established Lucene-wide guarantee; the report is that today's code follows neither.

One fix was validated through gradle in a scratch worktree of 645d4fe14a20. The alternative, returning at once and documenting it, is a policy choice for maintainers; it was not run.

Wrap the get() in a loop: on InterruptedException record one ThreadInterruptedException and retry; on a result or an ExecutionException leave the loop.

while (true) {
  try {
    results.add(future.get());
    break;
  } catch (InterruptedException e) {
    if (interrupted == false) {   // report the interrupt once, keep waiting
      interrupted = true;
      exc = IOUtils.useOrSuppress(exc, new ThreadInterruptedException(e));
    }
  } catch (ExecutionException e) {
    exc = IOUtils.useOrSuppress(exc, e.getCause());
    break;
  }
}

Trade-offs

• An interrupt no longer frees the calling thread before its running tasks end. It waits as long as it already waits for the other tasks today, and as after a task failure. Cancellation stays with the supported mechanisms (query timeouts, ExitableDirectoryReader).
• The interrupt flag stays cleared, as today and as IndexWriter documents for its own interrupts; restoring it before the throw is a separate choice (not run). Further interrupts during the same wait are not recorded separately, and the flag is not restored for them.
• Cancelling not-yet-started tasks would not help: when collectResults runs every task is already claimed, and cancel(false) cannot stop a task that is running (at most it would skip one claimed in the instant before its run() starts).

What the checks validated

• Gradle, scratch worktree of 645d4fe14a20, OpenJDK 25.0.3, seed DEADBEEF (2026-10-31): stock, the minimal test fails with assertions on and off. With the fix: the minimal test passes (10.2 s), TestTaskExecutor 10/10 and TestIndexSearcher 10 passed, 1 skipped by an assumption, 0 failures; the minimal test also passes with assertions off; TestTaskExecutor with seed 5EEDCAFE and 3 iterations: 30 tests, 0 failures. Formatting was not checked.
• Earlier checks: the study's 5 tests pass (the interrupt is still reported; task 0's late exception is attached as suppressed), the independent tie-break's 3 tests pass with assertions on and off, and the TLA+ model with the fix is clean (73 distinct states).

On InterruptedException, stop waiting and throw; change the javadoc and the cancel comment to say that running tasks may outlive the call, and make the assertion skip the interrupted case.

Trade-offs

Frees the interrupted caller at once, like the JDK's invokeAll, but brings back what #12523 removed for task failures: tasks that outlive the call, lost exceptions, and slices that can touch a reader the caller closes next. Running tasks cannot be interrupted either, because Task#cancel rejects mayInterruptIfRunning.

Method: formal (TLA+ model checking, the tool's own counterexample, then public-API JUnit tests).

• Model. TaskExec.tla models invokeAll with nesting, rejecting executors, exceptions, cancellation and interrupts of the application thread (the JDK's FutureTask.get() throws only if the task is not done and the flag is set).
• Counterexamples. Configuration te_intr: the worker runs task 1, the caller runs task 2, the caller is interrupted while it waits on future 1, and invokeAll completes while task 1 is still running: invariant NoRunningAfterReturn violated, 10-state trace. te_intr_exc_lost: the task then throws, and the exception is never reported (NoLostException). With the fix (keep waiting after an interrupt) every configuration is clean.
• Confirmation. A separate verifier wrote a 5-test class (4 fail, the control passes, on 10.1.0, 10.5.2 and main). The repro was reduced to one test; a later tie-break wrote an independent test with standard JDK pools and a real Future.cancel(true), which fails 10 of 10 on main, 10.5.2 and 10.6.0.