What is structured concurrency, and how does cancellation actually propagate through a coroutine/task tree?

#What "Structured" Means Here

Structured concurrency borrows the same idea that structured programming imposed on control flow decades ago: instead of a goto that jumps anywhere in the program, control flow nests inside blocks with a clear entry and a clear exit. Structured concurrency does the same thing to tasks: the lifetime of any concurrent work you launch is nested inside the scope of the code that launched it. A scope does not finish executing until every task it launched has also finished — successfully, with an error, or cancelled.

#The Three Guarantees

In any real structured-concurrency implementation (Kotlin coroutines, Python's asyncio.TaskGroup, scoped async/await), three guarantees hold:

1. A scope does not complete until all of its children complete. There is no way to "exit" a structured-concurrency block while leaving orphaned work running behind it.
2. If a child fails, its siblings are cancelled and the exception propagates to the parent. There is no silently-failed task whose error nobody ever observes.
3. Cancelling the scope cancels every descendant. Cancellation flows downward through the whole tree, not just to the direct child.

Compare that to unstructured concurrency — a raw Thread you never join, a goroutine launched with no channel to report its result, a Promise you never attach a .catch to. In every one of those cases, the work can keep running after the function that launched it has already returned, its errors can be lost silently, and there is no natural point at which to cancel it if it's no longer needed.

#Kotlin: coroutineScope, Job Trees, and Cancellation

In Kotlin, every coroutine has a Job that forms a parent-child tree. The coroutineScope { ... } builder creates a child scope that suspends until every coroutine launched inside it finishes, and if any of them throws, it cancels its siblings and rethrows to whoever called coroutineScope.

import kotlinx.coroutines.*

suspend fun fetchUser(id: Int): String {
    delay(100)
    return "user-" + id
}

suspend fun fetchOrders(id: Int): List<String> {
    delay(50)
    throw IllegalStateException("orders service unavailable")
}

suspend fun loadDashboard(userId: Int) {
    try {
        coroutineScope {
            val user = async { fetchUser(userId) }
            val orders = async { fetchOrders(userId) }

            // If fetchOrders throws, coroutineScope cancels the
            // sibling `user` coroutine and rethrows here.
            println("Dashboard: " + user.await() + ", " + orders.await())
        }
    } catch (e: IllegalStateException) {
        println("Failed to load dashboard: " + e.message)
    }
}

fetchOrders fails at 50ms, before fetchUser finishes (100ms). When that happens, coroutineScope cancels the still-active user coroutine, and fetchOrders's exception propagates out of coroutineScope to the caller's catch. Nothing is left running in the background once the function returns — that's the structured guarantee in action.

Cleanup still works exactly like sequential code, with try/finally:

suspend fun watchDownload(): Unit = coroutineScope {
    launch {
        try {
            while (isActive) {
                delay(200)
                println("...downloading...")
            }
        } finally {
            println("cleanup: closing file handle")
        }
    }
}

#Cancellation Is Cooperative

Cancelling a coroutine does not forcibly stop it mid-CPU-instruction — it requests, via a CancellationException, that it stop at the next cooperative suspension point (delay, yield, any suspending call that checks isActive). That means a very common bug is accidentally catching that exception:

// WRONG: this catch block also swallows cancellation, so the
// coroutine never actually stops and the parent scope hangs
// waiting for it forever.
launch {
    try {
        doWork()
    } catch (e: Exception) {
        log.warn("work failed", e)   // CancellationException is an Exception too!
    }
}

The fix is to catch CancellationException separately and rethrow it, or to avoid catching bare Exception in the first place:

launch {
    try {
        doWork()
    } catch (e: CancellationException) {
        throw e   // let cancellation keep propagating
    } catch (e: Exception) {
        log.warn("work failed", e)
    }
}

#supervisorScope: Opting Out of Sibling Cancellation

Sometimes child tasks are genuinely independent, and one failing shouldn't take down the others — loading three independent dashboard widgets, for example. supervisorScope (or a root Job created with SupervisorJob()) breaks the sibling-cancellation propagation, although each child's own exception still isn't lost if you handle it explicitly:

suspend fun loadWidgets(userId: Int) = supervisorScope {
    val weather = async { fetchWeather() }
    val news = async { fetchNews() }
    val stocks = async { fetchStocks() }

    // Each widget is independent: one failing must not cancel the others.
    listOf(weather, news, stocks).map { deferred ->
        try {
            deferred.await()
        } catch (e: Exception) {
            "unavailable"
        }
    }
}

#Python's Answer: asyncio.TaskGroup

Before Python 3.11, composing asyncio tasks in a structured way took manual discipline with asyncio.gather and careful attention to cancellation. asyncio.TaskGroup, added in 3.11, is the direct equivalent of coroutineScope: it is an async context manager that waits for every task created inside it to finish, and if one fails, cancels the others and groups the exceptions together.

import asyncio

async def fetch_user(user_id: int) -> str:
    await asyncio.sleep(0.1)
    return "user-" + str(user_id)

async def fetch_orders(user_id: int) -> list[str]:
    await asyncio.sleep(0.05)
    raise RuntimeError("orders service unavailable")

async def load_dashboard(user_id: int) -> None:
    try:
        async with asyncio.TaskGroup() as tg:
            user_task = tg.create_task(fetch_user(user_id))
            orders_task = tg.create_task(fetch_orders(user_id))
        print("dashboard:", user_task.result(), orders_task.result())
    except* RuntimeError as eg:
        for exc in eg.exceptions:
            print("failed to load dashboard:", exc)

The except* syntax handles an ExceptionGroup — because inside a TaskGroup, more than one task could fail at the same time, and Python needs a mechanism to report several exceptions without discarding any of them. The behavior mirrors Kotlin exactly: when fetch_orders fails, fetch_user (if it's still running) gets cancelled, and no task is left orphaned once the async with block exits.

#The Cancellation Tree