Skip to content
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

Add to test function the param context #23

Conversation

JavierSegoviaCordoba
Copy link

@JavierSegoviaCordoba JavierSegoviaCordoba commented Jan 27, 2021

  • context: CoroutineContext uses Unconfined as default param

Personally, I found a problem where the Unconfined context was throwing a TimeoutCancellationException. If I change it to EmptyCoroutineContext, the problem is gone.

- `context: CoroutineContext` uses `Unconfined` as default param
@JavierSegoviaCordoba JavierSegoviaCordoba changed the title Add to test function two params, start and context Add to test function the param context Jan 27, 2021
@JakeWharton
Copy link
Member

As discussed on Slack, I do not see this as viable API.

How does someone know what this value means? What do they pass to this? When is unconfined appropriate? When is something else appropriate? What behavior changes occur when you pass different things to this?

You're effectively adding a workaroundMySpecificProblem: Boolean = true which is not suitable for our public API.

I would suggest isolating your case and reporting it to the coroutines repo to see what JetBrains thinks about it.

@JavierSegoviaCordoba
Copy link
Author

I tried to create a minimal project which reproduces the issue but I had no luck :/

Have you checked the repo I gave you? I can share it directly to JetBrains if you think it is a coroutines issue and not something related to my code or turbine.

@JakeWharton
Copy link
Member

I am on paternity leave until mid-March so I'm not really looking at anything related to work or open source that takes longer than a few seconds.

@JavierSegoviaCordoba
Copy link
Author

I still have this in mind, I have to get time to clean up the repo and trying to get a minimal sample to reproduce the issue. After that, I will open an issue in coroutines, hopefully in March.

@JavierSegoviaCordoba
Copy link
Author

@JakeWharton doing some tests and with runBlocking the test passes, but with runBlockingTest it is failing.

Maybe it is related directly to Kotlin/kotlinx.coroutines#1204?

Another thing I would like to know is, why the lib should force to use a specific CoroutineStart and CoroutineContext? Every use case in the world should work with these specific params with no problems?

@JakeWharton
Copy link
Member

We start undispatched so as to ensure the collector is suspended waiting on an item before triggering the upstream collection. We use unconfined to run on the emission thread since we want the test to have access to the emission without the need to suspend which potentially allows unrelated coroutines to run and trigger even more emissions before the first was processed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants