Hey guys hi I wonder how do you handle infinite flow subscri

Question

Hey guys hi I wonder how do you handle infinite flow subscriptions Currently the only way works for me is ``` flow lt Unit gt while true delay 3000 emit Unit flowOn onEach gt intent reduce it launchIn viewModelScope ``` Unfortunately `intent` coroutine couldn t be used for this as it would block all new messages from the RealContainer s channel ``` intent flow lt Unit gt while true delay 3000 emit Unit flowOn onEach gt intent reduce it collect ```

Mikolaj Leszczynski · Answer

I thought we had a test or recommendation for this but for the life of me I can t find it I think we need to update our docs I think we tested it with something to this extent ```intent withContext <http Dispatchers IO|Dispatchers IO> flow lt Unit gt while true delay 3000 emit Unit collect reduce it ```

Mikolaj Leszczynski · Answer

let me know whether this works or not it should in theory but it s not well tested enough AFAICS

Mikolaj Leszczynski · Answer

you don t really need to wrap `reduce` in `intent` I don t think

Mikolaj Leszczynski · Answer

changing the context should help unblock the orbit event loop I m not sure how that relates to `flowOn` Mainly you need to make sure that you re collecting the flow on another dispatcher

Mikolaj Leszczynski · Answer

If that still doesn t look like it works please file a bug report and we ll look into it

Mikolaj Leszczynski · Answer

looks like we even have a ticket for it <https github com orbit mvi orbit mvi issues 15>

Oleksii Malovanyi · Answer

< Mikolaj Leszczynski> nah it still won t work as the parent coroutine from the `RealContainer` still waits for `collect` to finish and it never finishes I ve tried to modify `RealContainer` to receive channel s messages as a flow in a separate coroutine but the problem is `reduce` state is in a race condition then disappointed I ll try to play around it a bit and propose to move our conversation to github s issue top

Mikolaj Leszczynski · Answer

Odd I need to run some tests too

Mikolaj Leszczynski · Answer

Just to rule things out are you observing this behaviour in production code or tests

Oleksii Malovanyi · Answer

prod

Oleksii Malovanyi · Answer

I ll upload test branch with a possible way to fix in 5 mins

Oleksii Malovanyi · Answer

< Mikolaj Leszczynski>

Mikolaj Leszczynski · Answer

Thanks I ll take a look

Mikolaj Leszczynski · Answer

Today

Mikolaj Leszczynski · Answer

This is an important issue wink

Oleksii Malovanyi · Answer

btw as a concept I thought about two more variants 1 add another dsl method for infinite loops 2 provide child scope as a part of simple context e g for `launchIn` to not to block the `intent` with `collect` But surely wouldn t go with either if we still could make `intent` work safely without blocking

Mikolaj Leszczynski · Answer

Yeah that s what I m going to try to figure out

Mikolaj Leszczynski · Answer

I apologize we should have tested this better

Mikolaj Leszczynski · Answer

But I think this feature got lost somewhere when we transitioned from the strict to the simple syntax

Oleksii Malovanyi · Answer

while your lib is free you should apologise for nothing joy still grateful for your efforts

Mikolaj Leszczynski · Answer

I expect better from myself stuck out tongue winking eye

Mikolaj Leszczynski · Answer

Life s been getting in the way of improving this lib though

Mikolaj Leszczynski · Answer

< Oleksii Malovanyi> I ve figured it out So the reason it doesn t work and why I could have sworn it worked earlier grinning face with one large and one small eye is that we broke it when introducing the exception handler change Specifically the supervisorScope will wait until the coroutines inside it are finished This means it will indeed block forever when we collect an infinite flow The bug eluded us because it worked when an exception handler was not installed which is the case for the majority of tests so unit tests didn t pick it up I ve replaced the supervisor scope with a job instead PR ready here

Mikolaj Leszczynski · Answer

I ll release a hotfix as soon as this is in

Mikolaj Leszczynski · Answer

Just tagged <https github com orbit mvi orbit mvi releases tag 3 1 1>

Oleksii Malovanyi · Answer

< Mikolaj Leszczynski> wow Also the corresponding code looks now much smoother metal I feel a bit bad for introducing the issue but I also feel thankful for such a quick fix from your side Thanks

Mikolaj Leszczynski · Answer

Relax it did go through a code review and we haven t noticed

Mikolaj Leszczynski · Answer

Code doesn t break only if you never add any new features stuck out tongue winking eye

Mikolaj Leszczynski · Answer

Besides it was only confined to people having an exception handler installed I think we caught it early enough that most people don t have one

miqbaldc · Answer

thanks < CPM6UMD2P|orbit mvi> team amp < Oleksii Malovanyi> for the report heart

Mikolaj Leszczynski · Answer

there was some sort of hiccup in the maven central upload process but we will finalise the release today for sure