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

Fix wait condition evaluation issue #259

Merged
merged 4 commits into from
Jun 4, 2024
Merged

Conversation

cretz
Copy link
Member

@cretz cretz commented Jun 3, 2024

What was changed

This fixes/reverts an issue caused by #242. Specifically that issue scheduled condition checks as a task and just ran all tasks to completion. The problem is that we don't re-schedule the condition checks after the tasks that the conditions caused to wake up are completed. So we have effectively reverted that issue to return to evaluating conditions inline, but we added a feature to allow Workflow access from inside the conditionals.

💥 WARNING This is technically a history backwards incompatible change for anyone that has used 1.1.1 and has relied on wait conditions to be woken up after other coroutines set values. After discussion it was determined that short life and limited use of of the 1.1.1 release allows us to fix this 3-week bug. But this can technically cause non-determinism in those upgrading from 1.1.1 in that it can make a condition properly be re-evaluated a second time in a task where it wasn't before. Users before 1.1.1 are not affected.

@cretz cretz requested a review from a team June 3, 2024 19:41
@cretz
Copy link
Member Author

cretz commented Jun 3, 2024

This has become a bit more challenging on forever-waiting conditions, moving to draft while I work it out...

@cretz cretz marked this pull request as draft June 3, 2024 20:28
@cretz
Copy link
Member Author

cretz commented Jun 3, 2024

Updated to basically revert #242, please review

// Check conditions. It would be nice if we could run this in the task scheduler
// because then users could have access to the `Workflow` context in the condition
// callback. However, this cannot be done because even just running one task in the
// scheduler causes .NET to add more tasks to the scheduler. And you don't want to

Choose a reason for hiding this comment

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

What other tasks is dotnet adding ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Just looked at stack trace, it seems like this is actually in my stack trace logic at

return task.ContinueWith(
(and just below it for the return-type-based one) which is occurring during stack trace test (stack trace disabled by default in .NET). So I could technically disable stack trace continuations during condition checking, but I think the behavior here in the PR of not pushing the condition checks into the task queue is the best anyways.

@cretz cretz marked this pull request as ready for review June 3, 2024 22:32
@cretz cretz merged commit 83670a0 into temporalio:main Jun 4, 2024
7 checks passed
@cretz cretz deleted the wait-condition-fix branch June 4, 2024 13:40
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