Cooperative cancellation limits in NonCancellable cleanup blocks

Answer the question first

Inside a NonCancellable block the coroutine ignores CancellationException that would normally terminate the block. Because a withTimeout throws a TimeoutCancellationException (a subclass of CancellationException), the timeout is swallowed and the cleanup keeps running until it finishes on its own. The only way to enforce a hard limit is to move the timeout into a child coroutine that is *not* running in the NonCancellable context.

Confirmed facts

• NonCancellable suppresses CancellationException but does not suppress other exceptions.
• TimeoutCancellationException is a CancellationException, so it is ignored inside NonCancellable.
• Launching a child coroutine with its own timeout keeps the parent NonCancellable block short‑lived.
• Structured concurrency guarantees that a parent coroutine will wait for all its children; a hanging child inside NonCancellable will block the parent.

Safe patterns

1. Child scope with timeout

   withContext(NonCancellable) {
       coroutineScope { // creates a new child scope
           withTimeoutOrNull(5_000L) { // 5‑second limit
               cleanup() // may block or suspend
           }
           // optional: handle null (timed out) here
       }
   }

   This launches a new child coroutine that will be cancelled by the timeout. The parent NonCancellable block finishes as soon as the child completes or times out.

2. Launch and join with timeout

   withContext(NonCancellable) {
       val job = launch {
           withTimeoutOrNull(5_000L) { cleanup() }
       }
       job.join() // returns immediately if the job timed out
   }

   The job is a sibling of the NonCancellable block and is cancelled by the timeout. The parent does not wait for the child to finish beyond the timeout.

3. SupervisorJob + timeout

   val supervisor = SupervisorJob()
   withContext(NonCancellable + supervisor) {
       launch {
           withTimeoutOrNull(5_000L) { cleanup() }
       }
       // parent continues; any failure in the child is ignored by SupervisorJob
   }

   SupervisorJob prevents a failing child from cancelling the parent, but you still need the explicit timeout.

4. Blocking I/O

   If cleanup() performs blocking I/O that cannot be cancelled, run it on a dedicated thread:

   withContext(NonCancellable) {
       withContext(Dispatchers.IO + SupervisorJob()) {
           withTimeoutOrNull(5_000L) { blockingCleanup() }
       }
   }

Practical verification

Run a quick test:

runBlocking {
    val start = System.currentTimeMillis()
    launch {
        withContext(NonCancellable) {
            coroutineScope {
                withTimeoutOrNull(200L) {
                    delay(10_000L) // pretend long work
                }
            }
        }
    }
    println("finished after ${System.currentTimeMillis() - start} ms")
}

You should see the outer coroutine finish in roughly 200 ms, confirming the timeout was honored.

Missing diagnostic detail

Does the cleanup perform blocking I/O (e.g., FileChannel.flush()) that cannot be cancelled by a coroutine timeout? If so, consider moving it to a separate thread or using a withContext(Dispatchers.IO) block with a timeout.