Skip to content

1093: Launch Side Effects atomically so they are always started #1102

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

Closed
wants to merge 1 commit into from

Conversation

steve-the-edwards
Copy link
Contributor

@steve-the-edwards steve-the-edwards commented Aug 9, 2023

Add headlessIntegrationTest to renderWorkflowIn with a nice Turbine attached.

Check that we do not use the Unconfined dispatcher within the Workflow runtime as it does not provide ordering guarantees. Coroutines are resumed on whatever thread was last suspended. This means we could start sending actions within a side effect into a unfrozen RenderContext as we cannot guarantee the ordering of handling side effects.

Update documentation and tests to note the need to use a Dispatcher other than Dispatchers.Unconfined.

@steve-the-edwards steve-the-edwards force-pushed the sedwards/atomic-side-effects branch 2 times, most recently from 38f4e05 to c1b5d1f Compare August 9, 2023 22:07
@steve-the-edwards steve-the-edwards force-pushed the sedwards/atomic-side-effects branch 2 times, most recently from bb695ea to fd02fec Compare August 10, 2023 19:01
Comment on lines -114 to -118
* - The dispatcher is always set to [Unconfined][kotlinx.coroutines.Dispatchers.Unconfined] to
* minimize overhead for workers that don't care which thread they're executed on (e.g. logging
* side effects, workers that wrap third-party reactive libraries, etc.). If your work cares
* which thread it runs on, use [withContext][kotlinx.coroutines.withContext] or
* [flowOn][kotlinx.coroutines.flow.flowOn] to specify a dispatcher.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was just out-dated. Not true for some time (since GUWT and side effects I think), but we hadn't updated documentation.

@@ -543,35 +485,6 @@ class RenderWorkflowInTest {
}
}

@Test
fun `side_effects_from_initial_rendering_in_non_root_workflow_are_never_started_when_initial_render_of_non_root_workflow_fails`() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we repurpose these tests to confirm that they are run?

@steve-the-edwards steve-the-edwards force-pushed the sedwards/atomic-side-effects branch from fd02fec to 1b1acda Compare August 10, 2023 21:54
Solves #1093

Add headlessIntegrationTest to use for the new test case
@steve-the-edwards steve-the-edwards force-pushed the sedwards/atomic-side-effects branch from 1b1acda to 9f24c0d Compare August 10, 2023 21:55
@steve-the-edwards
Copy link
Contributor Author

steve-the-edwards commented Aug 11, 2023

This doesn't work because while the wrapped coroutine will be started, the block declared and passed to runningSideEffect will never be called.

UPDATE: that will only happen for nested Workflows - but this is actually a lot of them. I'm going to update the test case to be nested to see if it would fail.

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.

2 participants