supervisorScope is useful when sibling operations have independent outcomes. A direct child's failure does not automatically cancel the other direct children. It still waits for children before returning, and cancellation from its caller still cancels the work.
Assume the account is required but the recommendation service is optional:
suspend fun loadHome(): Home = supervisorScope {
val account = async { repository.loadAccount() }
val recommendations = async { repository.loadRecommendations() }
val accountValue = account.await()
val suggested = try {
recommendations.await()
} catch (failure: IOException) {
emptyList()
}
Home(accountValue, suggested)
}
The expected optional network failure becomes a fallback. If the account fails, its exception escapes the scope body, so the remaining children are cancelled. Unexpected recommendation failures also escape rather than silently pretending nothing is wrong.
Supervision is not an exception handler, and it is not “fire and forget.” An unhandled failure in a supervised launch still needs a reporting policy. It also only changes the relationship at that supervision boundary; a nested ordinary coroutine still has normal child-failure behavior.
Would you use it for a payment and inventory reservation? Not merely to keep both running. Those operations require an explicit consistency and compensation design. Failure isolation does not create a transaction.
Mark this when you can explain the answer in your own words.
Help fellow developers prepare for interviews
Sharing helps the Android community grow 💚