10/03/2019, 10:01 PM
Got a flow question for y'all.. It's about ....
Exception in thread "main" java.lang.IllegalStateException: Flow invariant is violated:
		Emission from another coroutine is detected.
		Child of StandaloneCoroutine{Active}@2b552920, expected child of BlockingCoroutine{Completing}@2758fe70.
		FlowCollector is not thread-safe and concurrent emissions are prohibited.
		To mitigate this restriction please use 'channelFlow' builder instead of 'flow'


10/03/2019, 10:02 PM
seems like you need to use the


10/03/2019, 10:03 PM
I do.. But.. I was wanting this to be really suspendable instead of multi-thready...
I have a example main thing I wrote up to show what I', shooting for
the channelFlow worked.. But.. I'm new to flows and rxjava-style code in general..
and I was wondering if that was the "correct way"
I stubbed out the asynchttpclient's completablefuture w/ a faked one.
Fixed the initial compile issues. I made a second copy of the gist w/ channelFlow and it didn't work out well. 🙂
Just checking to see if I'm doing anything just "wrong" here. if I replaced the flow w/ channelFlow(and emit to send), it works perfectly. But... I'm just checking to see if I'm going down the right path

Paul Woitaschek

10/04/2019, 6:41 AM
@taer Set the extension of your gist file to .kt so we get syntax highlighting

10/04/2019, 4:41 PM
The problem is you are doing
which means you'll emit from that new scope. You indeed need to use a channel-based flow to communicate between the contexts.


10/04/2019, 7:26 PM
Updated now. It's all now channelFlow based. I think this is probably correct.
The thing I was wondering about is .. Is this "best practice"? The 2 subFlows I have are simulated. The real code calls a http service that can wait up to 60 seconds, but returns a nice completableFuture. So, I think this is correct. All the printing seems to indicate this is working like I'd expect.
But it doesn't feel like this is 100% idiomatic. I'd love any pointers on how to make this less async'y and more suspend only.