Run wait-condition callbacks in workflow context #242
Conversation
There was a problem hiding this comment.
So git diff makes these changes look a bit scarier than they are. We just moved the run-all-task loop into a separate method, then enqueue the condition checker task instead of invoking it inline (issuing a run-all-task again for that new task).
| var task = scheduledTasks.Last!.Value; | ||
| scheduledTasks.RemoveLast(); | ||
| scheduledTaskNodes.Remove(task); | ||
| _ = QueueNewTaskAsync(CheckConditionsAsync); |
There was a problem hiding this comment.
For my own understanding in dotnet, Do we detect if the user tries to call any illegal APIs in the wait condition?
There was a problem hiding this comment.
We don't and we probably should. We have been mostly counting on the fact that it's not async to prevent commands, but there are commands like upsert search attribute that are not async. This is actually a gap for queries and update validators too. I have opened #243.
|
This caused a bug. Now conditions in coroutines depending on each other may not move forward because conditions are not re-run upon task resumption. |
What was changed
Changed logic to make the wait condition callbacks a task in so it is run within the workflow context so the user can access things on the
Workflowstatic classChecklist