-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
flowOn seems not consistent over time #2462
Comments
Thanks for the self-contained report! In your test, you have (after watering down all the machinery) three coroutines: Depending on whether |
Hi @qwwdfsad thanks a lot for your nice explanation. Is there a way to not use TestCoroutineDispatcher and force the execution of the reducer to an expected Thread ? I’ve tried to do so, but the whole loop doesn’t run anymore. It seems mandatory to use a TestCoroutineDispatcher at some point. The point of my test here is to ensure that the reducing takes place on the dispatcher used in the ´flowOn’ statement. Instead of testing the Thread name/id, do you know a way to identify the currently used dispatcher ? It could avoid the fact that the thread used by the TestCoroutineDispatcher is not reliable in my case ? thanks for your help. |
You can use |
Defines two test dispatchers: * StandardTestDispatcher, which, combined with runTest, gives an illusion of an event loop; * UnconfinedTestDispatcher, which is like Dispatchers.Unconfined, but skips delays. By default, StandardTestDispatcher is used due to the somewhat chaotic execution order of Dispatchers.Unconfined. TestCoroutineDispatcher is deprecated. Fixes #1626 Fixes #1742 Fixes #2082 Fixes #2102 Fixes #2405 Fixes #2462
Defines two test dispatchers: * StandardTestDispatcher, which, combined with runTest, gives an illusion of an event loop; * UnconfinedTestDispatcher, which is like Dispatchers.Unconfined, but skips delays. By default, StandardTestDispatcher is used due to the somewhat chaotic execution order of Dispatchers.Unconfined. TestCoroutineDispatcher is deprecated. Fixes #1626 Fixes #1742 Fixes #2082 Fixes #2102 Fixes #2405 Fixes #2462
Defines two test dispatchers: * StandardTestDispatcher, which, combined with runTest, gives an illusion of an event loop; * UnconfinedTestDispatcher, which is like Dispatchers.Unconfined, but skips delays. By default, StandardTestDispatcher is used due to the somewhat chaotic execution order of Dispatchers.Unconfined. TestCoroutineDispatcher is deprecated. Fixes #1626 Fixes #1742 Fixes #2082 Fixes #2102 Fixes #2405 Fixes #2462
Defines two test dispatchers: * StandardTestDispatcher, which, combined with runTest, gives an illusion of an event loop; * UnconfinedTestDispatcher, which is like Dispatchers.Unconfined, but skips delays. By default, StandardTestDispatcher is used due to the somewhat chaotic execution order of Dispatchers.Unconfined. TestCoroutineDispatcher is deprecated. Fixes #1626 Fixes #1742 Fixes #2082 Fixes #2102 Fixes #2405 Fixes #2462
This commit introduces the new version of the test module. Please see README.md and MIGRATION.md for a thorough discussion of the changes. Fixes Kotlin#1203 Fixes Kotlin#1609 Fixes Kotlin#2379 Fixes Kotlin#1749 Fixes Kotlin#1204 Fixes Kotlin#1390 Fixes Kotlin#1222 Fixes Kotlin#1395 Fixes Kotlin#1881 Fixes Kotlin#1910 Fixes Kotlin#1772 Fixes Kotlin#1626 Fixes Kotlin#1742 Fixes Kotlin#2082 Fixes Kotlin#2102 Fixes Kotlin#2405 Fixes Kotlin#2462 Co-authored-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
This commit introduces the new version of the test module. Please see README.md and MIGRATION.md for a thorough discussion of the changes. Fixes Kotlin#1203 Fixes Kotlin#1609 Fixes Kotlin#2379 Fixes Kotlin#1749 Fixes Kotlin#1204 Fixes Kotlin#1390 Fixes Kotlin#1222 Fixes Kotlin#1395 Fixes Kotlin#1881 Fixes Kotlin#1910 Fixes Kotlin#1772 Fixes Kotlin#1626 Fixes Kotlin#1742 Fixes Kotlin#2082 Fixes Kotlin#2102 Fixes Kotlin#2405 Fixes Kotlin#2462 Co-authored-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
Hi every one,
It'd like to submit an issue we've had in our team regarding the design of a feedback loop architecture.
We've implemented a test that was supposed to ensure that our reducer function was always called on the expected Thread (in our unit test, abstracted by a TestCoroutineDispatcher).
In our test, we have 2 feedbacks that perform side effects on their respective and dedicated dispatchers (backed by SingleThreadContext). Every time the loop iterates, we check that the side effects are run on the expected Threads and the reducer is also executed in the expected Thread.
When executed once, the test works fine. When executed several times then we start to see that the reducing can take place in a feedback dedicated Thread. It seems to be completely random. I'd say that on 200 executions of the test, 30 can fail because of that.
We try to ensure the reducer is executed on the expected dispatcher thanks to a
flowOn()
statement. We've also tried the execute it inside awithContext()
statement, but we noticed the same behaviour.At that point, we do not know if our implementation has an issue, or if the Flow api has an issue. Any help would be appreciated 👍.
Coroutine version is 1.4.1.
Here is the code of the Unit Test:
The text was updated successfully, but these errors were encountered: