InterruptedException swallowed, breaking cancellation

What this error actually means

Interruption in Java is a single boolean flag on the `Thread` object plus a convention about how to respond to it. Every blocking method that declares `InterruptedException` does the same thing when it sees the flag set: it **clears the flag** and throws. That clearing is the part almost everyone misses. By the time your `catch` block runs, the thread no longer remembers that it was interrupted, and the only record of the request is the exception object you are holding.

So catching it and logging it does not merely hide an error — it destroys the cancellation request. The exception is the delivery mechanism, and dropping it is equivalent to receiving a shutdown signal and deciding not to pass it on. Every later check of `isInterrupted()` returns false, every subsequent blocking call proceeds normally, and the task continues indefinitely while the code that requested cancellation believes it succeeded.

This is what makes `Future.cancel(true)` report `true` for a task that keeps running. `cancel` marks the future cancelled and interrupts the worker thread; it makes no attempt to verify the task actually stopped, because it cannot. The return value means "the cancellation was requested and the task had not already completed", not "the task has stopped". A task that swallows the exception makes the two permanently different.

The failure then propagates outward into things that look unrelated. `ExecutorService.shutdownNow()` relies on interruption, so the pool never terminates and the JVM will not exit. Timeout wrappers that cancel on expiry leak the work they meant to abandon. A retry loop wrapping a swallowed interrupt becomes a busy loop that survives SIGTERM, which is how one swallowed exception turns into a pod that must be SIGKILLed on every deploy.

How to diagnose it

grep -rn -A 4 "catch (InterruptedException" src/main/java | grep -v "interrupt()" | grep -v "throw"

log.info("loop top: interrupted={}", Thread.currentThread().isInterrupted());

f.cancel(true);
assertTrue(stoppedLatch.await(2, TimeUnit.SECONDS), "task ignored cancellation");

grep -c "interrupted" app.log   # compare against the number of cancellations issued

jcmd <pid> Thread.print | grep -A 6 "poll-worker"

The fix

Prefer propagating the exception. If the method can declare `throws InterruptedException`, let it — the caller is better placed to decide whether to stop, and propagation preserves the flag semantics for free. Declaring it is a design statement that the method is cancellable, which is information callers need.

Where you cannot propagate — a `Runnable`, a framework callback, a constructor — restore the flag before leaving: `Thread.currentThread().interrupt()` and then return or break out of the loop. Restoring without exiting is only half the fix; the point of the flag is that the next blocking call or the pool worker sees it and stops.

Structure worker loops so the interrupt condition is the loop condition: `while (!Thread.currentThread().isInterrupted())`. That way both a thrown `InterruptedException` and a bare flag set on a compute-bound task terminate the loop, and the cancellation path does not depend on which blocking call happened to be in flight.

For CPU-bound work with no blocking call, poll the flag at a granularity that matches your cancellation deadline — once per batch, per row chunk, per iteration of the outer loop. There is no other way to make compute-bound work cancellable, and unbounded compute is a common reason shutdowns miss their budget.

Never let `InterruptedException` be caught by a broad `catch (Exception e)` that retries. Catch it first and separately, above the general handler, so a cancellation can never be mistaken for a transient failure. This ordering is what prevents the unstoppable retry loop.

In cleanup and shutdown code, restore the flag and force the pool down: catch, call `shutdownNow()`, restore the interrupt, and return. Shutdown paths are the last place you can afford to lose the signal, because a swallowed interrupt there means the process cannot exit.

Prefer timeouts over cancellation where the semantics allow it. A blocking call with a bounded wait ends on its own and needs no cooperation, which removes an entire category of "the task ignored us" problems.

// Broken: the flag is cleared, the loop continues, the task is uncancellable
while (true) {
    try {
        poll();
        Thread.sleep(5_000);
    } catch (InterruptedException e) {
        log.warn("interrupted", e);       // flag already cleared; loop continues
    }
}

// Also broken: propagates the failure but loses the cancellation request
try {
    queue.take();
} catch (InterruptedException e) {
    throw new IllegalStateException(e);   // flag still clear for callers above
}

// Correct: exit the loop, and restore the flag for whoever runs next on this thread
while (!Thread.currentThread().isInterrupted()) {
    try {
        poll();
        Thread.sleep(5_000);
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();   // restore
        break;                                // and stop
    }
}

// Correct: propagate where the signature allows it
Item next() throws InterruptedException {
    return queue.poll(1, TimeUnit.SECONDS);   // caller decides
}

// Correct: compute-bound work must poll, because nothing will throw
for (int i = 0; i < rows.size(); i++) {
    if ((i & 0x3FF) == 0 && Thread.currentThread().isInterrupted()) {
        throw new CancellationException("aborted at row " + i);
    }
    transform(rows.get(i));
}

How to stop it coming back

• Make "catch of `InterruptedException` must restore the flag or exit" an enforced static-analysis rule, not a review convention
• Order catch blocks so `InterruptedException` is always handled before any broad `catch (Exception)` that retries
• Write cancellation tests that assert the task stops within a deadline, never that `cancel` returned true
• Shape every worker loop as `while (!Thread.currentThread().isInterrupted())` so both delivery mechanisms terminate it
• Poll the interrupt flag inside long compute loops at a known granularity, and document what that granularity costs you at shutdown
• Include a SIGTERM-under-load test that fails if the process does not exit inside the grace period — that is what catches the remaining cases

FAQ

Related

Other errors engineers hit next to this one

• ERROR: canceling statement due to conflict with recovery
• psycopg2.InterfaceError: connection already closed
• RecursionError: maximum recursion depth exceeded
• MemoryError: unable to allocate array
• QueuePool limit of size 5 overflow 10 reached, connection timed out
• DetachedInstanceError: instance is not bound to a Session
• RuntimeError: Event loop is closed
• Task was destroyed but it is pending!