{"id":620,"date":"2026-09-29T14:20:00","date_gmt":"2026-09-29T12:20:00","guid":{"rendered":"https:\/\/grindloop.io\/blog\/?p=620"},"modified":"2026-09-26T15:27:28","modified_gmt":"2026-09-26T13:27:28","slug":"viewmodelscope-launch-supervisorjob-crash","status":"publish","type":"post","link":"https:\/\/grindloop.ai\/blog\/viewmodelscope-launch-supervisorjob-crash\/","title":{"rendered":"Why viewModelScope.launch(SupervisorJob()) Still Crashes Your App"},"content":{"rendered":"

An UploadViewModel<\/code> sends several photos at once. A teammate wrapped each upload in launch(SupervisorJob())<\/code>. The goal was that one failed upload can’t take down the rest. Two bug reports come back from QA. On a flaky connection, a failed upload still crashes the app. And if the user backs out mid-upload, the uploads keep running. What’s wrong?<\/p><\/blockquote>\n\n\n

class UploadViewModel(\n    private val repo: PhotoRepository\n) : ViewModel() {\n\n    private val _state = MutableStateFlow(UploadState())\n    val state: StateFlow<UploadState> = _state\n\n    fun upload(photos: List<Photo>) {\n        photos.forEach { photo ->\n            \/\/ \"Isolate\" each upload so one failure can't kill the others\n            viewModelScope.launch(SupervisorJob()) {\n                val url = repo.upload(photo) \/\/ throws IOException on a bad connection\n                _state.update { it.withUploaded(photo.id, url) }\n            }\n        }\n    }\n}<\/pre>\n\n\n
Passing SupervisorJob()<\/code> to launch<\/code> doesn’t make a coroutine safer. It replaces the coroutine’s parent. The new coroutine is no longer a child of viewModelScope<\/code>. Its only parent is a fresh SupervisorJob<\/code> that nothing else knows about. Two bugs follow from that. First, a failure still crashes the app. A SupervisorJob<\/code> doesn’t handle a child’s exception. It passes it on as an uncaught exception. On Android, an uncaught exception ends the process. Second, the upload no longer stops when the ViewModel is cleared. Cancelling viewModelScope<\/code> can’t reach a coroutine it isn’t the parent of. The kotlinx.coroutines launch<\/code> docs call passing a Job<\/code> here incorrect, because it “breaks structured concurrency.” The fix is to drop the argument. Then catch the exception inside the coroutine. viewModelScope<\/code> is built on a SupervisorJob<\/code>, so it already isolates its children.<\/p>\n\n
What launch(SupervisorJob()) actually does to the parent<\/h2>\n\n
Most candidates read launch(SupervisorJob())<\/code> as “launch this with supervisor behavior.” That isn’t how a coroutine context works for Job<\/code>. Every coroutine creates its own Job<\/code>. A Job<\/code> passed in the context doesn’t become the coroutine’s job. It becomes its parent.<\/p>\n\n
The kotlinx.coroutines launch<\/code> reference<\/a> spells this out. Normally the Job<\/code> in the scope’s context is used as the parent. “Passing a Job in context overrides the parent and is forbidden.” The same page lists what happens when you do it anyway. If the scope is cancelled, “the new coroutine will not be affected.” If the coroutine fails, the exception goes to the passed Job<\/code> instead of the scope. And if that Job<\/code> is a SupervisorJob<\/code>, “the exception will be unhandled.”<\/p>\n\n
JetBrains added an IDE inspection for this pattern. It’s called “Job used as an argument in a coroutine starter.” It’s available since IntelliJ IDEA 2025.3. JetBrains explains it in a March 2026 post on the new coroutine inspections<\/a>. The Job<\/code> argument “overrides Job<\/code> from the scope and becomes a parent. This breaks structured concurrency.”<\/p>\n\n
Bug 1: SupervisorJob() doesn’t stop the crash<\/h2>\n\n
A SupervisorJob<\/code> changes one thing. A failing child doesn’t cancel the supervisor or its other children. The Kotlin exception-handling guide<\/a> is explicit about the cost. “Every child should handle its exceptions by itself.” The child’s exception goes to a CoroutineExceptionHandler<\/code> if one is in the context. There isn’t one here.<\/p>\n\n
With no handler, the CoroutineExceptionHandler<\/code> reference<\/a> describes the JVM fallback. The current thread’s Thread.uncaughtExceptionHandler<\/code> is invoked. On Android, that’s a crash. The Android vitals crash page<\/a> says an unhandled exception crashes the app.<\/p>\n\n
viewModelScope<\/code> is already built on a SupervisorJob<\/code>. Here is createViewModelScope()<\/code> from CloseableCoroutineScope.kt<\/code><\/a> in androidx-main:<\/p>\n\n\n
internal fun createViewModelScope(): CloseableCoroutineScope {\n    val dispatcher = try {\n        Dispatchers.Main.immediate\n    } catch (_: NotImplementedError) {\n        EmptyCoroutineContext\n    } catch (_: IllegalStateException) {\n        EmptyCoroutineContext\n    }\n    return CloseableCoroutineScope(coroutineContext = dispatcher + SupervisorJob())\n}<\/pre>\n\n\n
So a plain viewModelScope.launch { }<\/code> already has supervisor behavior toward its siblings. One failed upload never cancelled the others. It also already crashed the app, because the same rule applies. The extra SupervisorJob()<\/code> changed nothing about failures. It only broke cancellation.<\/p>\n\n
Bug 2: the upload outlives the ViewModel<\/h2>\n\n
When the ViewModel is cleared, viewModelScope<\/code> is cancelled. That cancellation travels down to the scope’s children. These uploads aren’t its children anymore. Their parent is a SupervisorJob<\/code> that nobody ever cancels.<\/p>\n\n
So each upload runs to completion after the user has left. The lambda still holds repo<\/code> and _state<\/code>. That keeps the cleared ViewModel reachable until the upload finishes. It then writes into a StateFlow<\/code> no screen collects anymore. If the upload later fails, it still reaches the uncaught handler. That’s a crash from a screen the user already closed.<\/p>\n\n
The behavior, reproduced<\/h2>\n\n
This small JVM program rebuilds viewModelScope<\/code> the same way, SupervisorJob()<\/code> plus a single “main” thread. It installs a default uncaught handler that prints instead of killing the process. It runs on kotlinx.coroutines 1.10.2.<\/p>\n\n\n
val mainThread = Executors.newSingleThreadExecutor { r -> Thread(r, \"main\") }\n    .asCoroutineDispatcher()\nfun fakeViewModelScope() = CoroutineScope(SupervisorJob() + mainThread)\n\nfun main() = runBlocking {\n    Thread.setDefaultUncaughtExceptionHandler { t, e ->\n        println(\"  !! uncaught on '${t.name}': $e  (on Android: process dies)\")\n    }\n\n    println(\"1: failure inside launch(SupervisorJob())\")\n    val s1 = fakeViewModelScope()\n    try {\n        s1.launch(SupervisorJob()) { throw IllegalStateException(\"upload failed\") }\n    } catch (e: Exception) {\n        println(\"  caught by try\/catch: $e\") \/\/ never prints\n    }\n    delay(200)\n\n    println(\"2: scope cancelled while launch(SupervisorJob()) runs\")\n    val s2 = fakeViewModelScope()\n    val job = s2.launch(SupervisorJob()) {\n        repeat(5) { i ->\n            delay(100)\n            println(\"  still uploading chunk $i, scope active=${s2.isActive}\")\n        }\n    }\n    delay(150); s2.cancel(); println(\"  scope cancelled\")\n    job.join()\n\n    println(\"3: plain launch fails, sibling in the same scope\")\n    val s3 = fakeViewModelScope()\n    s3.launch { delay(50); throw IllegalStateException(\"upload failed\") }\n    s3.launch { delay(200); println(\"  sibling finished, scope active=${s3.isActive}\") }\n        .join()\n    mainThread.close()\n}<\/pre>\n\n\n\n
1: failure inside launch(SupervisorJob())\n  !! uncaught on 'main': java.lang.IllegalStateException: upload failed  (on Android: process dies)\n2: scope cancelled while launch(SupervisorJob()) runs\n  still uploading chunk 0, scope active=true\n  scope cancelled\n  still uploading chunk 1, scope active=false\n  still uploading chunk 2, scope active=false\n  still uploading chunk 3, scope active=false\n  still uploading chunk 4, scope active=false\n3: plain launch fails, sibling in the same scope\n  !! uncaught on 'main': java.lang.IllegalStateException: upload failed  (on Android: process dies)\n  sibling finished, scope active=true<\/pre>\n\n\n
Case 1 shows the crash path. The try<\/code>\/catch<\/code> around launch<\/code> never fires. launch<\/code> doesn’t rethrow its body’s exception to the caller. Case 2 shows four chunks uploading after the scope was cancelled. Case 3 is the plain launch<\/code> the teammate replaced. The sibling survives. The failure still reaches the uncaught handler. The crash behavior is identical. Cancellation still works too.<\/p>\n\n
The fix: drop the argument and catch inside the coroutine<\/h2>\n\n\n
fun upload(photos: List<Photo>) {\n    photos.forEach { photo ->\n        viewModelScope.launch {\n            try {\n                val url = repo.upload(photo)\n                _state.update { it.withUploaded(photo.id, url) }\n            } catch (e: IOException) {\n                _state.update { it.withFailed(photo.id, e) }\n            }\n        }\n    }\n}<\/pre>\n\n\n
Each upload is a child of viewModelScope<\/code> again. Leaving the screen cancels all of them. Siblings stay isolated because the scope’s own SupervisorJob<\/code> already does that. The failure is handled where it happens, turned into UI state instead of a crash. This matches the Android coroutines best-practices page<\/a>. It says to catch likely exceptions inside the coroutine body. That applies to “any coroutines created with viewModelScope<\/code> or lifecycleScope<\/code>.”<\/p>\n\n
Catch IOException<\/code>, not Exception<\/code>. A broad catch (e: Exception)<\/code> also catches the CancellationException<\/code> thrown when the user leaves. That turns a normal cancellation into a fake “upload failed” state.<\/p>\n\n
If the parallel uploads live in a suspend function instead, use supervisorScope { }<\/code>. It’s the structured version of what the teammate wanted. Per the Kotlin guide, it propagates cancellation in one direction only. It also waits for all its children. The caller’s cancellation still reaches them. The children still need their own try<\/code>\/catch<\/code>.<\/p>\n\n\n
suspend fun uploadAll(photos: List<Photo>): List<UploadResult> = supervisorScope {\n    photos.map { photo ->\n        async {\n            try {\n                UploadResult.Success(photo.id, repo.upload(photo))\n            } catch (e: IOException) {\n                UploadResult.Failed(photo.id, e)\n            }\n        }\n    }.awaitAll()\n}<\/pre>\n\n\n
What if the upload really must finish after the user leaves? A detached SupervisorJob<\/code> is still the wrong tool. The best-practices page recommends an external CoroutineScope<\/code> for that. Something that lives longer than the screen should own it. The Application<\/code> class is one option. The detachment is then deliberate and has one owner.<\/p>\n\n
The rule to remember<\/h2>\n\n
Don’t pass Job()<\/code> or SupervisorJob()<\/code> to launch<\/code>, async<\/code> or withContext<\/code>. It picks a new parent. It doesn’t change behavior.<\/strong><\/p>\n\n