A modern programming language that makes developers happier.

kotlinlang

I’m not usually one to post an SO question, but i feel like it’s relevant here, and it could use some more attention:

<https://stackoverflow.com/questions/62747825/coroutine-stateflow-stops-emitting-when-coroutinescope-is-cancelled>

This sounds like a bug, did you file one?

No - I just assumed this is intended behavior

How could I recognise/argue that its a bug?

Looks like you're basically implementing stateIn manually - I wonder if it has the same behavior

Yeah, I don’t _think_ `stateIn` for StateFlow is released yet? I remember reading some github comments where it was proposed, and then I decided to basically emulate the same behavior.

Because I’m relatively new to coroutines, it’s hard for me to understand whether that part is relevant or not. The `stateIn` equivalent here is just ‘feeding’ the `StateFlow` values - I feel like this`JobCancellationException` issue should occur independently of whatever is passing values to the `StateFlow`. In other words, the downstream consumer’s scope is cancelled, passing a `JobCancellationException` up the hierarchy, to the `StateFlow`. The coroutine feeding values to the `StateFlow` is secondary, or possibly outside the scope of this issue. (Maybe?)

If I can figure out how, I’ll test whether this occurs with `stateIn`

You're correct, stateIn hasn't been released yet.

Can you tell me what makes you think this a bug? I’ve been trying to understand this scope/context stuff for a couple days.. When the scope is cancelled, it’s expected that a JobCancellationException is propagated up the chain, right? So that the job and its parents can be cancelled?

have you tried to minimize the code (removing your MVP classes, android dependencies, libraries, etc) that demonstrates your issue?
to something like <https://pl.kotl.in/XaLM2jj6j>
But with the sample above canceling downstream doesn't affect state flow producer scope.

No, I haven’t. I’ll see if I can reproduce the issue in the playground

Actually, if you remove your final 2 lines of code:
```    //delay(3000)
    //job2.cancelAndJoin()```
It looks like you can reproduce the issue

You’ll notice that collector 2 stops collecting values shortly after job1 is cancelled

Oh, hmm. Looks like I don’t understand the playground all that well

if you remove delay/join - main fun completes and main process just terminates

OK, yeah, interesting. I can’t replicate this in the playground

This was my mistake. My test method was flawed - I was cancelling the scope of the coroutine, then attempting to bind() the same presenter again (thinking it was a new instance of presenter). So this _is_ behaving as expected