I’m not usually one to post an SO question, but i feel like it’s relevant here, and it could use som...

# coroutines

[Tim Malseed]

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

[Zach Klippenstein (he/him) [MOD]]

This sounds like a bug, did you file one?

[Tim Malseed]

No - I just assumed this is intended behavior

[Tim Malseed]

How could I recognise/argue that its a bug?

[Zach Klippenstein (he/him) [MOD]]

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

[Tim Malseed]

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?)

[Tim Malseed]

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

[Zach Klippenstein (he/him) [MOD]]

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

[Tim Malseed]

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?

[bezrukov]

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.

[Tim Malseed]

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

[Tim Malseed]

Actually, if you remove your final 2 lines of code:

//delay(3000)
    //job2.cancelAndJoin()

It looks like you can reproduce the issue

[Tim Malseed]

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

[Tim Malseed]

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

[bezrukov]

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

[Tim Malseed]

Yeah, I see that now 🤦

[Tim Malseed]

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

[Tim Malseed]

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