Hey ```class FooViewModel private val appScope CoroutineScop

Question

Hey ```class FooViewModel private val appScope CoroutineScope ViewModel fun fooClicked viewModelScope launch delay 2000 withContext appScope coroutineContext lt Should run even when view user clicks back i e view model cleared delay 2000 ``` Is this a correct way to run something even after view model scope is cancelled view model cleared on back press I was used to just `appScope launch ` i e to launch a new couroutine in the higher scope explicitly This way of `withContext` seems to work as well but feels wrong Opinions Doesn t it leak `viewmodel this` during the lambda execution

uli · Answer

gt This way of `withContext` seems to work as well but feels wrong That s surprising because structural concurrency is a feature of the CoroutineScope not of the Context and `withContext` only replaced the Context as far as I know gt Doesn t it leak `viewmodel this` during the lambda execution True there is a risk but only if you reference the ViewModel But how would that work any way accessing the view model for more than it s life cycle Btw same would be true for the lambda of `launch`

ursus · Answer

gt That s surprising You mean that it feels wrong to me or that it works smile

uli · Answer

It s surprising that it works

streetsofboston · Answer

Using the other scope s Job in the appScope coroutineContext like this doesn t seem quite right I think it s better to switch CoroutineScopes appScope to properly communicate between objects with different lifecycles scopes

ursus · Answer

Yea it never occurred to me to make it work this way until this code review I always tried to do something like this ```class FooViewModel private val something SomethingInHigherScope ViewModel fun fooClicked viewModelScope launch delay 2000 sometihng thatSomething class SomethingInHigherScope private val appScope CoroutineScope fun thatSomething appScope launch Should run even when view user clicks back i e view model cleared delay 2000 ```

streetsofboston · Answer

Also I would not expose `appScope` publicly like this or pass it to the method of another object which can run the risk of the other object accidentally do something destructive to it eg cancelling it accidentally

ursus · Answer

but one benefit of the surprising version is that you can execute stuff after `thatSomething` synchronously

streetsofboston · Answer

ie I d put appScope launch inside a method of another object with the appScope lifecycle

ursus · Answer

with mine you d have to expose some flows or a Job it self to join on

ursus · Answer

yea scope injecting is another question I too have a private scope in `SomethingInHigherScope` but then you need a explicit destructor

streetsofboston · Answer

You could expose return the Job returned by appScope launch

ursus · Answer

yea but should you tbh that also feels wrong smile running the action on my scope but then letting callsites control it

ursus · Answer

best would probably be some sort of Job interface which doesnt allow for cancellation just joining

ursus · Answer

anyways back to the original would you consider the `withContext appScope coroutineScope ` pattern a antipattern some sideffect desired behavior

uli · Answer

It just does not work <https play kotlinlang org eyJ2ZXJzaW9uIjoiMS44LjEwIiwicGxhdGZvcm0iOiJqYXZhIiwiYXJncyI6IiIsIm5vbmVNYXJrZXJzIjp0cnVlLCJ0aGVtZSI6ImlkZWEiLCJjb2RlIjoiaW1wb3J0IGtvdGxpbi5jb3JvdXRpbmVzLipcbmltcG9ydCBrb3RsaW54LmNvcm91dGluZXMuKlxuaW1wb3J0IGtvdGxpbi5jb25jdXJyZW50LnRocmVhZFxuaW1wb3J0IGtvdGxpbi5jb3JvdXRpbmVzLnJlc3VtZVxuaW1wb3J0IGtvdGxpbi50aW1lLipcblxuc3VzcGVuZCBmdW4gbWFpbigpIHtcbiAgICB2YWwgdmlld01vZGVsU2NvcGUgPSBDb3JvdXRpbmVTY29wZShEaXNwYXRjaGVycy5EZWZhdWx0KVxuICAgIHZhbCBhcHBTY29wZSA9IENvcm91dGluZVNjb3BlKERpc3BhdGNoZXJzLkRlZmF1bHQpXG4gICAgdmlld01vZGVsU2NvcGUubGF1bmNoKCkge1xuICAgICAgICBwcmludGxuKFwiQ29yb3V0aW5lIGxhdW5jaGVkIGluIHZpZXdNb2RlbFNjb3BlIVwiKVxuICAgICAgICB3aXRoQ29udGV4dChhcHBTY29wZS5jb3JvdXRpbmVDb250ZXh0KSB7XG4gICAgICAgIHByaW50bG4oXCJDb3JvdXRpbmUgbGF1bmNoZWQgaW4gYXBwU2NvcGU XCIpXG4gICAgICAgICAgICBkZWxheSgyMDAwKVxuICAgICAgICAgICAgcHJpbnRsbihcIlR3byBzZWNvbmRzIHBhc3NlZFwiKVxuICAgICAgICB9XG4gICAgfVxuICAgIGRlbGF5KDEwMDApXG5cdHZpZXdNb2RlbFNjb3BlLmNhbmNlbCgpXG59In0=|https play kotlinlang org eyJ2ZXJzaW9uIjoiMS44LjEwIiwicGxhdGZvcm0iOiJqYXZhIiwiYXJncy RlbGF5KDEwMDApXG5cdHZpZXdNb2RlbFNjb3BlLmNhbmNlbCgpXG59In0=>

ursus · Answer

interesting I also thought it would not work but testing it on android it does

ursus · Answer

maybe some sideffect of the android Main dispatcher

uli · Answer

I <https play kotlinlang org eyJ2ZXJzaW9uIjoiMS44LjEwIiwicGxhdGZvcm0iOiJqYXZhIiwiYXJncyI6IiIsIm5vbmVNYXJrZXJzIjp0cnVlLCJ0aGVtZSI6ImlkZWEiLCJjb2RlIjoiaW1wb3J0IGtvdGxpbi5jb3JvdXRpbmVzLipcbmltcG9ydCBrb3RsaW54LmNvcm91dGluZXMuKlxuaW1wb3J0IGtvdGxpbi5jb25jdXJyZW50LnRocmVhZFxuaW1wb3J0IGtvdGxpbi5jb3JvdXRpbmVzLnJlc3VtZVxuaW1wb3J0IGtvdGxpbi50aW1lLipcblxuZnVuIG1haW4oKSA9IHJ1bkJsb2NraW5nKERpc3BhdGNoZXJzLkRlZmF1bHQpIHtcbiAgICB2YWwgdmlld01vZGVsU2NvcGUgPSBDb3JvdXRpbmVTY29wZShEaXNwYXRjaGVycy5EZWZhdWx0KVxuICAgIHZhbCBhcHBTY29wZSA9IENvcm91dGluZVNjb3BlKERpc3BhdGNoZXJzLkRlZmF1bHQpXG4gICAgdmlld01vZGVsU2NvcGUubGF1bmNoKCkge1xuICAgICAgICBwcmludGxuKFwiQ29yb3V0aW5lIGxhdW5jaGVkIGluIHZpZXdNb2RlbFNjb3BlIVwiKVxuICAgICAgICB3aXRoQ29udGV4dChhcHBTY29wZS5jb3JvdXRpbmVDb250ZXh0KSB7XG4gICAgICAgICAgICB0cnkge1xuXHQgICAgICAgICAgICBwcmludGxuKFwiQ29yb3V0aW5lIGxhdW5jaGVkIGluIGFwcFNjb3BlP1wiKVxuICAgIFx0ICAgICAgICBkZWxheSgyMDAwKVxuICAgICAgICBcdCAgICBwcmludGxuKFwiVHdvIHNlY29uZHMgcGFzc2VkXCIpXG4gICAgICAgICAgICB9IGNhdGNoIChjOiBDYW5jZWxsYXRpb25FeGNlcHRpb24pIHtcbiAgICAgICAgICAgICAgICBwcmludGxuKFwiYXBwU2NvcGUgY2FuY2VsZWQ6IGNcIilcblx0XHRcdFx0dGhyb3cgY1xuICAgICAgICAgICAgfVxuICAgICAgICB9XG4gICAgfVxuICAgIGRlbGF5KDEwMDApXG5cdHZpZXdNb2RlbFNjb3BlLmNhbmNlbCgpXG4gICAgZGVsYXkoMzAwMClcbn0ifQ==|updated my test case > and can confirm that it work as you say

ursus · Answer

but why you only moved to a blocking `main` thats all

uli · Answer

i prevented main from exiting

ursus · Answer

okay so `suspend` main is not a thing

uli · Answer

not sure maybe the final delay made the difference

ursus · Answer

anyways what now haha smile

ursus · Answer

I did see `withContext NonCancellable ` in the docs which seem somewhat similar but that s a `AbstractCoroutineContextElement` so probably doesn t apply

uli · Answer

I ll post that back to the channel

uli · Answer

Hi there can any one explain why the `delay 1000 ` is not canceled in <https play kotlinlang org eyJ2ZXJzaW9uIjoiMS44LjEwIiwicGxhdGZvcm0iOiJqYXZhIiwiYXJncyI6IiIsIm5vbmVNYXJrZXJzIjp0cnVlLCJ0aGVtZSI6ImlkZWEiLCJjb2RlIjoiaW1wb3J0IGtvdGxpbi5jb3JvdXRpbmVzLipcbmltcG9ydCBrb3RsaW54LmNvcm91dGluZXMuKlxuaW1wb3J0IGtvdGxpbi5jb25jdXJyZW50LnRocmVhZFxuaW1wb3J0IGtvdGxpbi5jb3JvdXRpbmVzLnJlc3VtZVxuaW1wb3J0IGtvdGxpbi50aW1lLipcblxuZnVuIG1haW4oKSA9IHJ1bkJsb2NraW5nKERpc3BhdGNoZXJzLkRlZmF1bHQpIHtcbiAgICB2YWwgdmlld01vZGVsU2NvcGUgPSBDb3JvdXRpbmVTY29wZShEaXNwYXRjaGVycy5EZWZhdWx0KVxuICAgIHZhbCBhcHBTY29wZSA9IENvcm91dGluZVNjb3BlKERpc3BhdGNoZXJzLkRlZmF1bHQpXG4gICAgdmlld01vZGVsU2NvcGUubGF1bmNoKCkge1xuICAgICAgICBwcmludGxuKFwiQ29yb3V0aW5lIGxhdW5jaGVkIGluIHZpZXdNb2RlbFNjb3BlIVwiKVxuICAgICAgICB3aXRoQ29udGV4dChhcHBTY29wZS5jb3JvdXRpbmVDb250ZXh0KSB7XG4gICAgICAgICAgICB0cnkge1xuXHQgICAgICAgICAgICBwcmludGxuKFwiQ29yb3V0aW5lIGxhdW5jaGVkIGluIGFwcFNjb3BlP1wiKVxuICAgIFx0ICAgICAgICBkZWxheSgxMDAwKVxuICAgICAgICBcdCAgICBwcmludGxuKFwiT25lIHNlY29uZCBwYXNzZWRcIilcbiAgICAgICAgICAgIH0gY2F0Y2ggKGM6IENhbmNlbGxhdGlvbkV4Y2VwdGlvbikge1xuICAgICAgICAgICAgICAgIHByaW50bG4oXCJhcHBTY29wZSBjYW5jZWxlZDogY1wiKVxuXHRcdFx0XHR0aHJvdyBjXG4gICAgICAgICAgICB9XG4gICAgICAgIH1cbiAgICB9XG4gICAgZGVsYXkoNTAwKVxuXHR2aWV3TW9kZWxTY29wZS5jYW5jZWwoKVxuICAgIHByaW50bG4oXCJ2aWV3TW9kZWxTY29wZSBjYW5jZWxlZFwiKVxuICAgIGRlbGF5KDE1MDApXG4gICAgcHJpbnRsbihcIkRvbmVcIilcbn0ifQ==|this code> ```fun main = runBlocking Dispatchers Default val viewModelScope = CoroutineScope Dispatchers Default val appScope = CoroutineScope Dispatchers Default viewModelScope launch println Coroutine launched in viewModelScope withContext appScope coroutineContext try println Coroutine launched in appScope delay 1000 println One second passed catch c CancellationException println appScope canceled c throw c delay 100 viewModelScope cancel println viewModelScope canceled delay 1500 println Done ```

CLOVIS · Answer

The job is running in `appScope` not in `viewModelScope` You cancelled `viewModelScope` so it s not impacted

uli · Answer

I was expecting it to be running in viewModelScope with the context of the app scope

CLOVIS · Answer

The thing that decides whether a coroutine is cancelled is the `Job` instance which is stored in `coroutineContext` Print `coroutineContext` in all your println statements to see what is running in what What you give to `withContext` overrides the caller Because you used `appScope` s context which contains a `Job` the contents of `withContext` are children of that job and not of the caller s The caller suspends until `withContext` is over

CLOVIS · Answer

It s not really considered good practice to call `withContext` with a context that contains a Job exactly for this reason it detaches the child coroutine from the caller

streetsofboston · Answer

If you just want to make it non cancellable use `NonCancellable` in the withContext call or if you want to execute the async code on a different lifecycle a different scope launch it in that coroutine scope

CLOVIS · Answer

If you do want to detach the child from the parent it s much more readable to write ```appScope launch ``` than ```withContext appScope ``` but it essentially is the same thing the difference is with the latter option the coroutine will inherit all context elements that are not present in `appScope` from its parent e g a `CoroutineName`

ephemient · Answer

are you trying to launch something that can be cancelled by both `viewModelScope` and `appScope` a Job can only have one parent or zero

uli · Answer

No it was the OPs intent to not get that block canceled but I was surprised that it works

streetsofboston · Answer

I did some experimentations my self a long while ago with switching scopes slightly smiling face towards the bottom of this article0 <https medium com swlh how can we use coroutinescopes in kotlin 2210695f0e89>

ursus · Answer

okay so the exact reasoning being it is unexpected I have to say ```class EmailSender suspend fun sendEmail class NewEmailViewModel private val sender EmailSender private val appScope CoroutineScope fun sendClicked viewModelScope launch delay 1000 val job = appScope launch sender sendEmail job join somethingOther fun sendClicked2 viewModelScope launch delay 1000 withContext appScope coroutineContext sender sendEmail somethingOther ``` `withContext` seems like bit more natural api

CLOVIS · Answer

It really depends on what you want to do Indeed if you want to launch a job in another scope and only wait for it but not cancel it if you re cancelled it s clearer to use `withContext`

uli · Answer

maybe be more explicit and use ```withContext appScope coroutineContext job ```

ursus · Answer

so you d more precisely say it is unexpected that stuff launched into a scope could outlive the given scope i e structured concurrency and if you want to this you should be explicit about it explicit = `otherScope launch`

uli · Answer

yes or make it explicit in withContext that you intend to pass the job

ursus · Answer

tbh I never used `withContext ` with anything other than a dispatcher

CLOVIS · Answer

Yes most code but there are sometimes good reasons to deviate from the standard is to write code that either waits for a task to finish and cancels the task if it is cancelled fires and forget a task in another scope and doesn t wait for its results In your example why do you need to wait for the email to be sent

CLOVIS · Answer

I use `withContext` often with stuff like `CoroutineName` or my own custom context elements but I tend to avoid using it with a `Job`

ursus · Answer

no reason to wait for the email just to illustrate it is easy to do so vs having a Job join Flow lt EmailSentEvent gt boilerplate

CLOVIS · Answer

I think I recall someone from the coroutine team saying they would have liked to forbid `withContext` with a job but it s too late now because it would break code citation needed

ursus · Answer

But then `NonCancellable` could not exist no Which to me always felt like some sort of legacy solution to make some old blocking stuff work

ephemient · Answer

`NonCancellable` is useful in certain other circumstances <https kotlinlang org docs cancellation and timeouts html run non cancellable block|https kotlinlang org docs cancellation and timeouts html run non cancellable block>