If I want to make a child coroutine scope for my Repository so that the coroutines it launches are tied to application lifecycle rather than that of a view model or something more narrow what is the correct way to do that? Something like this?

// MyRepository.kt
class MyRepository<T>(coroutineScope: CoroutineScope) {
    private val scope = couroutineScope + Dispatchers.Default
    private val dataSource: DataSource<T> = DataSource()

    fun add(newValue: T) {
        scope.launch {
            dataSource.new(newValue)
        }
    }
}

// Example usage in a Compose Desktop app
// Main.kt
@Composeable
@Preview
fun App() {
    val appScope = rememberCoroutineScope { Dispatchers.Main }
    val repository = MyRepository(appScope)
    MainScreen(repository)
}

You've got the basic idea right, but you'll want to also give the Repository coroutineScope a

SupervisorJob()

so one failing task doesn't cancel the entire Repo (and thus, also the parent scope passed into the Repo). And when you add that job, make sure to set the parent job, so cancellation of the application scope also flows down and cancels the Repository.

Ahhh okay, so instead of

private val scope = coroutineScope + Dispatchers.Default

I probably want

private val scope = coroutineScope + SupervisorJob()

and in my repo functions if I want the default dispatcher I can specify that there.

Not quite, you need to explicitly join a “child job” to its parent job for cancellation to work properly,

SupervisorJob(parent = coroutineScope.coroutineContext.job)

. From the documentation of the

SupervisorJob

function:

If [parent] job is specified, then this supervisor job becomes a child job of its parent and is cancelled when its parent fails or is cancelled. All this supervisor’s children are cancelled in this case, too. The invocation of [cancel][Job.cancel] with exception (other than [CancellationException]) on this supervisor job also cancels parent.

Thank you for such a thorough explanation! I think all of this makes sense. W.r.t. the patterns you mentioned is one "better" than the other? What would be the benefit of creating a new scope and not overriding the job? Maybe to signal the intent that my repository has "narrower" scope than the application scope but without having to manage the job linkage myself?

If you’re creating a “child scope”, you almost certainly want to provide your own Job into that scope. By creating a new child scope, you’re basically stating that you are launching things into it in such a way that they are “owned” by that child scope, but they are not owned by the one passed in. The tasks launched in the child scope are owned by the child scope, so providing your own

Job

allows you to control all those child tasks. The alternative of not providing a

Job

at all would be considering the scope to simply be a “view” into a parent scope. In other words, the Repository itself is not meaningful, it’s not really doing anything, doesn’t have its own lifetime, isn’t handling errors, etc. I honestly can’t think of a use-case where you would create a child scope without a custom

Job

, since any situation where you would do this kind of thing would probably be done using

withContext

instead. In the case of using a Repository pattern, the Repository is its own thing and launched its own tasks, so it should have its own

Job

because it might have a lifetime that’s different from the parent scope, handle errors differently, etc. It’s linked to the parent scope only in the sense that when the parent is cancelled the Repository is also cancelled, but beyond that it should not expect the parent scope to handle errors thrown inside tasks launched by the Repository. For example, think of how unintuitive it would be if you had a RepositoryA throw an error, then both RepositoryA and RepositoryB get cancelled, despite RepositoryB not being related to RepositoryA at all. This is the kind of situation you might run into by not providing your own

Job

to each Repository’s child scope.

Yeah that makes a lot of sense, and to help convince myself I'm doing something more correct now I did some ol' trusty println debugging

class Repository(parentScope: CoroutineScope) {
    private val repositoryScope = run {
        val job = SupervisorJob(parent = parentScope.coroutineContext[Job]).apply { 
            invokeOnCompletion { println("Repository scope is being cancelled.") }
        }
        parentScope + Dispatchers.Default + job
    }
} 

// Main.kt
@Composable
fun App() {
    val applicationScope = rememberCoroutineScope { Dispatchers.Main }
    val repository = Repository(applicationScope)
    // etc etc
}

and when I close the application I see exactly what I expected which is "Repository scope is being cancelled." Also to demonstrate to myself what you said about not overriding the parent scope's job I also tried leaving out

parent = parentScope.coroutineContext[Job]

in the above code and watched as closing the app did not kill the associated process. Thanks for all your help here, I appreciate the discussion!