Skip to content
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

[Workflow] Add more documentation around purging #4020

Merged
merged 6 commits into from
Feb 9, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -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, including all its history. Each Dapr SDK exposes APIs for purging all metadata related to specific workflow instances.

## Workflow scalability

Because Dapr Workflows are internally implemented using actors, Dapr Workflows have the same scalability characteristics as actors. The placement service:
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -63,6 +63,8 @@ You can use the following two techniques to write workflows that may need to sch

1. **Use the _continue-as-new_ API**:
Each workflow SDK exposes a _continue-as-new_ API that workflows can invoke to restart themselves with a new input and history. The _continue-as-new_ API is especially ideal for implementing "eternal workflows", like monitoring agents, which would otherwise be implemented using a `while (true)`-like construct. Using _continue-as-new_ is a great way to keep the workflow history size small.

> The _continue-as-new_ API truncates the existing history, replacing it with a new history.

1. **Use child workflows**:
Each workflow SDK exposes an API for creating child workflows. A child workflow behaves like any other workflow, except that it's scheduled by a parent workflow. Child workflows have:
Expand Down Expand Up @@ -149,6 +151,12 @@ Workflows can also wait for multiple external event signals of the same name, in

Learn more about [external system interaction.]({{< ref "workflow-patterns.md#external-system-interaction" >}})

## 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 used for workflows that have run to a `COMPLETED`, `FAILED`, or `TERMINATED` state.

Learn more in [the workflow API reference guide]({{< ref workflow_api.md >}}).

## Limitations

### Workflow determinism and code restraints
Expand Down
4 changes: 4 additions & 0 deletions daprdocs/content/en/reference/api/workflow_api.md
Original file line number Diff line number Diff line change
Expand Up @@ -174,6 +174,10 @@ Purge the workflow state from your state store with the workflow's instance ID.
POST http://localhost:3500/v1.0-beta1/workflows/<workflowComponentName>/<instanceId>/purge
```

{{% alert title="Note" color="primary" %}}
Only `COMPLETED`, `FAILED`, or `TERMINATED` workflows can be purged.
{{% /alert %}}

### URL parameters

Parameter | Description
Expand Down
Loading