I'd like to ask about scope cancelation. Is it 100% synchronous?

someOtherPlace {
   someUserScope.launch {
       val userFlow: Flow<User?> = userDao.user()
       userFlow
        .collect {
             // can 'it' be null here?
         }
   }
}

fun logout() {
	allUserCoroutineScopes.forEach { it.cancel() }
	userDao.deleteUser()
}

lets assume

someUserScope

is in the

allUserCoroutineScopes

list, and I'll only delete user after running the cancelation forEach Is there a way the flow at the top will emit null? Should never happen, right? Is it safe to

!!

there? (I'm looking at sources but its non obvious to me)

no, it's not synchronous. Each cancelled coroutine that was suspended at time of cancellation will resume with a CancellationException on the coroutine's dispatcher. If you need to wait until all of those things are complete, you can do something like

allUserCoroutineScopes.forEach { it.coroutineContext.job.join() }

after the foreach/cancel line in your example above.

I'm a bit confused, do I care about the CancelationException? Isn't cancelation comunicated via the

awaitClose

and friends? Anyways, you're saying the the open flows could get canceled after

userDao.deleteUser()

, therefore they could emit null, right?

for a whole host of reasons they could still be running. You could probably align the stars such that you wouldn't encounter problems, but the easiest and most sure way to make sure you don't delete the user until you've stopped observing your user flow is to wait for all observers of the user flow to join before deleting it.

will the joining work if its a hot stream? Or do you mean something like

allUserCoroutineScopes.forEach { it.cancel() }
allUserCoroutineScopes.forEach { it.coroutineContext.job.join() }

Implementations of

collect

check if the coroutine is active before emitting(here). So if

someUserScope

uses a single threaded dispatcher and

logout

is only called from that thread, then you don't have to worry about the

collect

lambda being invoked after

logout

is called. However, if there's any possibility of multithreading, then you've lost your guarantee entirely. Also,

cancel

is 100% not synchronous at all not even a little. Even if one thread is involved, a previously invoked

collect

lambda could be suspended when you call

logout

, so the user could be deleted when the that other code resumes (not that it'll affect your locally captured

it

variable but it could cause other problems depending on your code.

Its bit more involved I just tried to keep it minimal. What Im trying to do is have

LoggedInUserProvider: Flow<User>

within loggedIn semantic DI scope, composed from

GlobalUserProvider: Flow<User?>

which is appscoped so it can be used outside the loggedin scope (and trying to discern how to create one, whether by asserting not null, or, just filtering) anyways…im still baffled by the stream emitting after scope cancelation Im sort of okay with already "in flight" emits finishing but source stream (

userDao.user()

) producing new emits after cancel? why? how is this not a problem? Is it just a transient issue due to multithreading or by design? I believe rx has isDisposed checks before emitting to prevent this very thing, or doesnt it?

there are a few questions all being asked at once here so let's separate them. Regarding flows in particular, see https://pl.kotl.in/yx_pPNFJB