mirror of https://github.com/dapr/docs.git
add purge to workflow docs
Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>
This commit is contained in:
parent
e27a24ea40
commit
59d0101c67
|
@ -145,6 +145,8 @@ Different state store implementations may implicitly put restrictions on the typ
|
|||
|
||||
Similarly, if a state store imposes restrictions on the size of a batch transaction, that may limit the number of parallel actions that can be scheduled by a workflow.
|
||||
|
||||
Workflow state can be purged from a state store, purging all its history. Purging removes all metadata related to a specific workflow instance.
|
||||
|
||||
## Workflow scalability
|
||||
|
||||
Because Dapr Workflows are internally implemented using actors, Dapr Workflows have the same scalability characteristics as actors. The placement service:
|
||||
|
|
|
@ -151,6 +151,15 @@ Learn more about [external system interaction.]({{< ref "workflow-patterns.md#ex
|
|||
|
||||
## Limitations
|
||||
|
||||
### Purging
|
||||
|
||||
Workflow state can be purged from a state store, purging all its history and removing all metadata related to a specific workflow instance. The purge capability is typically used for workflows that have run to a `COMPLETED` or `TERMINATED` state.
|
||||
|
||||
There are other times you may choose to purge a workflow history and reuse a workflow instance with new inputs, like:
|
||||
|
||||
- `CONTINUED_AS_NEW` state
|
||||
- A `FAILED` workflow instance
|
||||
|
||||
### Workflow determinism and code restraints
|
||||
|
||||
To take advantage of the workflow replay technique, your workflow code needs to be deterministic. For your workflow code to be deterministic, you may need to work around some limitations.
|
||||
|
|
Loading…
Reference in New Issue