-
Notifications
You must be signed in to change notification settings - Fork 33
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
Conversation
This has become a bit more challenging on forever-waiting conditions, moving to draft while I work it out... |
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 |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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( |
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.