Cancellation is cooperative (and your cleanup is cancelled too)

Cancellation is the feature that makes structured concurrency worth having: when a WebFlux client disconnects, when a `withTimeout` fires, when an Android screen is destroyed, the work underneath should stop — and stop *everywhere*, all the way down the tree of children. But the mechanism is not what most people assume. `job.cancel()` does not interrupt a thread and it does not abort a computation. It moves the Job into a *cancelling* state, and from that moment every **suspension point** inside that coroutine throws a `CancellationException` instead of resuming normally. Cancellation is delivered, not enforced.

The immediate consequence is that a coroutine which never suspends can never be cancelled. A tight loop doing CPU work — parsing a large file, running a simulation, hashing — has no suspension points, so `cancel()` sets the flag and the loop keeps running to completion regardless. The fix is to make the loop cooperate: call `ensureActive()` (which throws if the Job is cancelled), or check `isActive` yourself, or call `yield()` (which both checks for cancellation and gives other coroutines on the dispatcher a turn). Every suspending function in `kotlinx.coroutines` — `delay`, `await`, `Channel.send`, `Mutex.lock` — already checks for you; it is only *your own* non-suspending work that has to opt in.

The second consequence is the one that causes production bugs: a cancelled coroutine is *already* in the cancelling state when its `finally` block runs. Every suspension point in that block therefore throws immediately — so a cleanup like `finally { connection.closeAsync(); metrics.flush() }` written with suspending calls never executes a single line of it. The block runs, the first `delay`/`await` inside it throws, and the resource leaks. This is not a bug in the library; it is the cancellation contract applied consistently, and it surprises everyone exactly once.

`withContext(NonCancellable) { … }` is the escape hatch. It installs a Job that is never cancelled, so suspensions inside it behave normally, and it is the *only* legitimate use of `NonCancellable`: a short, bounded cleanup block. Wrapping business logic in it converts a cancellable coroutine into an unstoppable one, which is strictly worse than not supporting cancellation at all — the caller now believes it can stop the work and cannot. Keep the block small enough that you would be comfortable with it running to completion after a shutdown signal, because that is exactly what it will do.

`CancellationException` is also the reason broad exception handling is dangerous inside coroutines. It is an ordinary `Exception`, so `catch (e: Exception)` catches it, and so does `runCatching { }` (which catches `Throwable`). A retry wrapper written that way keeps looping after `cancel()`, producing a **zombie coroutine**: the parent scope has moved on, nobody will ever join it, and structured concurrency's central guarantee — when the scope returns, its children are finished — is quietly false. In a request-scoped server that is one leaked coroutine per cancelled request. The rule is absolute: either catch the specific exception you actually handle, or catch broadly and rethrow `CancellationException` first.

Cancellation propagates down and, for failures, up. Cancelling a parent cancels every child; a child that *fails* cancels its parent (which then cancels the siblings) unless the parent is a `SupervisorJob`. This is why `coroutineScope` and `supervisorScope` are a design decision rather than a style preference: the first says "these results only make sense together", the second says "these are independent best-effort tasks". Note the asymmetry — supervision stops *failure* travelling upward, but a cancelled supervisor still cancels its children. Supervision is not immunity.

A few APIs are worth knowing precisely. `cancel()` only *requests* cancellation and returns immediately, so reading state right after it is a race; `cancelAndJoin()` waits for the coroutine to finish unwinding. `withTimeout(t)` throws `TimeoutCancellationException` (a `CancellationException`, so it cancels the block rather than escaping as a normal error) while `withTimeoutOrNull(t)` returns `null` instead. `job.invokeOnCompletion { cause -> … }` gives you a non-suspending callback that runs on every terminal path, which is often a better place for bookkeeping than a `finally` that has to fight the cancellation contract.

The mental model to keep: cancellation is a *cooperative protocol*, not a kill switch. Your code participates by suspending often enough to notice, by not swallowing the signal, and by making its cleanup explicitly non-cancellable for the few milliseconds that takes. Code that does all three can be stopped instantly and leaves nothing behind; code that does none of them looks fine in tests and leaks under load, because it is only under load that anything actually gets cancelled.