Dmitry Khalanskiy

It looks to me like the pull-based model can be easily circumvented even by accident, as the rest of the facilities are not prepared for such use. The example above...

Could not reproduce. The test: ```kotlin import kotlinx.coroutines.* import org.junit.jupiter.api.* import java.io.* import java.util.concurrent.* class Reproducer3328 { @Test fun testSerialization() { val cdl = CountDownLatch(1) val bos = ByteArrayOutputStream() val...

The recommended solution, for now, is to use the Turbine library for testing flows. A quick workaround is to do the following: ```kotlin @Test fun testAllEmissions() = runTest { val...

> In production the two emissions will have maybe 1 second in between due to the network call (so it doesn't matter that StateFlows are conflated). Wouldn't it be a...

Do you mean that, in your tests, you actually do network calls etc., instead of mocking them, and the problem is that the test framework does not recognize that real...

> because the implementation of the service class can change at any time. If your implementation changes to one that fetches data immediately, then conflation can actually happen in this...

The issue you're having is that `loadItems` only emits the last value after 4 seconds have passed—at the virtual time of 4 seconds since the start of the test—but the...

> `dataRepository.loadRemoteData() // Loads after few seconds` > `coEvery { dataRepository.loadRemoteData() } returns listOf(something)` These lines are at odds with each other. The first line says that it's expected that...

Great! We have a public Slack channel, it is more suited for questions and improving understanding. Here, in the issue tracker, we try to limit the discussions to the actual...

I don't think this being an option on a SharedFlow is a good idea. It is stated everywhere that SharedFlow is, semantically, a *hot* stream of values, that is, it...