This PR adds support for activities. The basic approach is to create a new actor type that can execute activity logic, StatelessActivityActor. I call them "stateless" because they don't store any state. They do create reminders, but these are transient. There is one instance of this actor for every activity invocation. Because these actors are stateless, there shouldn't be any storage cost associated with creating a potentially unlimited number of actors for executing activities.
When an activity actor receives a request to execute an activity, it immediately stores that request in a reminder so that it can execute the activity in the background without blocking the invoking workflow. When the activity execution is complete, the activity actor will asynchronously call into the workflow actor to post the result. The workflow actor will then use a reminder to execute the next step in the workflow.
Implementation details
This PR also refactors the code to separate "workflow" code from "activity" code.
I've also created a new ReliableActor base class to help centralize logic around reminder management.
Unfortunately, I seem to have run into an issue where reminders are not getting properly cleaned up from the state store after being unregistered. I've opened an issue in the Dapr repo here: https://github.com/dapr/dapr/issues/4801. This bug seems to have two impacts to this code:
There's effectively a "leak" in the state store since we create a lot of reminders
We're unable to reuse reminder names
As a result of these issues, I've disabled the recurrence schedules of reminders, which is otherwise necessary to make workflows resilient to failures.
Resolves #2
Overview
This PR adds support for activities. The basic approach is to create a new actor type that can execute activity logic,
StatelessActivityActor. I call them "stateless" because they don't store any state. They do create reminders, but these are transient. There is one instance of this actor for every activity invocation. Because these actors are stateless, there shouldn't be any storage cost associated with creating a potentially unlimited number of actors for executing activities.When an activity actor receives a request to execute an activity, it immediately stores that request in a reminder so that it can execute the activity in the background without blocking the invoking workflow. When the activity execution is complete, the activity actor will asynchronously call into the workflow actor to post the result. The workflow actor will then use a reminder to execute the next step in the workflow.
Implementation details
This PR also refactors the code to separate "workflow" code from "activity" code.
I've also created a new
ReliableActorbase class to help centralize logic around reminder management.Unfortunately, I seem to have run into an issue where reminders are not getting properly cleaned up from the state store after being unregistered. I've opened an issue in the Dapr repo here: https://github.com/dapr/dapr/issues/4801. This bug seems to have two impacts to this code:
As a result of these issues, I've disabled the recurrence schedules of reminders, which is otherwise necessary to make workflows resilient to failures.