Vsevolod Tolstopyatov

Indeed, it's time to, thanks for pointing it out. If you have any other use-cases apart from the linked one (https://github.com/cashapp/zipline/blob/79cd02d6dfd4936c8de20fd3950a68a121fc8aee/zipline/src/commonMain/kotlin/app/cash/zipline/internal/bridge/flows.kt#L74-L83), please don't hesitate to share. The most interesting questions...

Hi, thanks for the reminder. Nothing conceptually prevents it, we just haven't bothered by looking into it deeply after the initial release -- API seemed to be well-received and no...

Thanks for the detailed report! We are looking into that, though it's quite hard to make any estimations regarding this

We initially thought about alternatives to the current behaviour. The biggest problem with the proposed one is that it's racy and may yield the unexpected result: everything is completed normally,...

Hi! We are not yet decided what to do. As soon as we merge #3324 (which is blocked by 1.7.0 regression, so we are waiting for 1.7.10) where definitely-non-nullable types...

Superseded by https://github.com/Kotlin/kotlinx.coroutines/pull/3393

This is indeed a bug, but it seems to be only fixable in 1.7.0. The story is the following: * `BufferOverflow` doesn't acknowledge `onUndeliveredElement` in any channels at all, except...

While we're evaluating it, could you folks please describe your use case for this?

Thanks, folks! That's not the use-cases we expected when designing this API, but they are definitely the ones we'd like to support

The best solution would be not to use runBlocking, but rather regular coroutines (e.g. `launch(Dispatcher.Main) {}`)