docs
docs copied to clipboard
dapr
[Workflow] Describe the nuanced behaviour of how external events are allocated
What content needs to be created or modified?
cc @cgillum @kaibocai
There is a particular nuance in Dapr Workflows (and Azure Durable Functions too) which leads people to believe that when the code is awaiting multiple external event Tasks in a when any pattern, once a single Task has been completed and a winner has been determined, then the non-winning task won't consume an event.
This is not true. The non-winning Task will continue to consume an event if such a matching event was to be raised throughout the life of the workflow instance, even though the workflow has advanced beyond the initial when any.
This problem is particularly evident when waiting for the same event (same event name) in a loop, here is an example an individual suspecting this is a bug, however it is not. - It's worth adding that this issue was created off the back of a user on Discord relaying their concern.
The guidance should be to use an Eternal Workflow pattern with ContinueAsNew, as this will remove any incomplete tasks and ensure that tasks are allocated correctly.
Describe the solution you'd like
Better docs to outline the above problem. The problem is almost touched on here, but this particular nuance is missed
Where should the new material be placed?
possibly here
The associated pull request from dapr/dapr, dapr/components-contrib, or other Dapr code repos
I agree with the sentiment and that we it would be good to clarify what happens as part of the "when-any" pattern for workflows. I'm not sure I understand the proposed solution, however.
The guidance should be to use an Eternal Workflow pattern with ContinueAsNew, as this will remove any incomplete tasks and ensure that tasks are allocated correctly.
From the description in this issue, I'm not seeing the connection here between "when-any" and "continue-as-new". One is for handling "races" in workflows and the other is for effectively running infinite loop workflows. I think the problem you're describing is specifically when combining "when-any" with loops, which I agree is a common source of misunderstanding and could be fixed with "continue-as-new". Other uses of "when-any" don't necessarily require this.
If you agree with my narrower problem statement, then I would propose instead making an addendum to Workflow Patterns / External system interaction. This is where users are introduced to the external event + "when-any" pattern and the "winner" concept. We can definitely add clarification here that the other task still runs and completes, and even go as far as warning against doing this in loops.
Thoughts?
