A modern programming language that makes developers happier.

kotlinlang

:mega: :mega: :mega: kotlinx.coroutines 1.6.0 is here!

• Brand new `kotlinx-coroutines-test` module with reworked API and multiplatform support
• `CoroutineDispatcher.limitedParallelism` and elastic `<http://Dispathers.IO|Dispathers.IO>`
• Out-of-the-box support of new K/N memory model
• `CopyableThreadContextElement` for mutable context elements
• And a lot of improvements and bug fixes: <https://github.com/Kotlin/kotlinx.coroutines/releases/tag/1.6.0>
We also have a <https://blog.jetbrains.com/kotlin/2021/12/introducing-kotlinx-coroutines-1-6-0/|blogpost> and <https://www.youtube.com/watch?v=9R1IdMwSVps|what’s new> video with additional details, examples and explanation

`native-mt` version is also here, and this is the last major version of coroutines with the support of `native-mt` builds: <https://github.com/Kotlin/kotlinx.coroutines/issues/462#issuecomment-999557659>

So this is using Kotlin 1.6? Didn't Kotlin 1.6 have a breaking bug? Why not Kotlin 1.6.10?

So is the expectation that by 1.7, most of the K/N community will have migrated to the new memory model? I'm a little surprised native-mt wouldn't be supported for one more release cycle in case people are slow to move over.

See <https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-test/README.md#virtual-time-support-with-other-dispatchers>
Turbine launches the `collect` of this flow in `Dispatchers.Unconfined`, which is not linked to `kotlinx-coroutines-test`: <https://github.com/cashapp/turbine/blob/trunk/src/commonMain/kotlin/app/cash/turbine/FlowTurbine.kt#L86>
So, the timeout runs with delay-skipping, whereas the flow body does not.

I would suggest turning off the timeout, as our test framework will also fail if the system hangs.
```    @Test
    fun myTest() = runTest {
        flow {
            yield()
            delay(10.milliseconds)
            emit(Unit)
        }.test(0) {
            assertEquals(Unit, awaitItem())
        }
    }```


Though this wouldn't solve most problems with how `test` is typically used. I think the long-term solution would be to ask Turbine to allow passing a dispatcher in which the flow should be collected. If this is done, passing an `UnconfinedTestDispatcher` there would make the flow aware of the delay-skipping.

Can you post your ideas here?
<https://github.com/cashapp/turbine/issues/71|https://github.com/cashapp/turbine/issues/71>

Nah, it's the opposite, actually. They're running the timeout just fine (and if they implement the change, it's also going to be fine), it's the flow's body that should run on a different dispatcher.

Here's the relevant issue: <https://github.com/cashapp/turbine/issues/42> I'll continue there.

It’s probably good if you communicate directly there as these two libraries closely belong together

I somehow missed the obvious solution that is not very verbose: <https://github.com/cashapp/turbine/issues/42#issuecomment-868681072>
So,
```    @Test
    fun myTest() = runTest {
        flow {
            delay(10.milliseconds)
            emit(Unit)
        }.flowOn(UnconfinedTestDispatcher(testScheduler))
        .test {
            assertEquals(Unit, awaitItem())
        }
    }```
