mirror of https://github.com/dapr/docs.git
Merge branch 'v1.12' into mikeee-init-docs
This commit is contained in:
mikeee
GitHub
commit
66d6e8f74b
|
|
@ -1,3 +1,3 @@
|
|||
# Contributing to Dapr docs
|
||||
|
||||
Please see [this docs section](https://docs.dapr.io/contributing/) for general guidance on contributions to the Dapr project as well as specific guidelines on contributions to the docs repo.
|
||||
Please see [this docs section](https://docs.dapr.io/contributing/) for general guidance on contributions to the Dapr project as well as specific guidelines on contributions to the docs repo. Learn more about [Dapr bot commands and labels](https://docs.dapr.io/contributing/daprbot/) to improve your docs contributing experience.
|
||||
|
|
@ -12,7 +12,7 @@ Dapr bot is triggered by a list of commands that helps with common tasks in the
|
|||
|
||||
| Command | Target | Description | Who can use | Repository |
|
||||
| ---------------- | --------------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------- |
|
||||
| `/assign` | Issue | Assigns an issue to a user or group of users | Anyone | `dapr`, `components-contrib`, `go-sdk` |
|
||||
| `/assign` | Issue | Assigns an issue to a user or group of users | Anyone | `dapr`, `docs`, `quickstarts`, `cli`, `components-contrib`, `go-sdk`, `js-sdk`, `java-sdk`, `python-sdk`, `dotnet-sdk` |
|
||||
| `/ok-to-test` | Pull request | `dapr`: trigger end to end tests <br/> `components-contrib`: trigger conformance and certification tests | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr`, `components-contrib` |
|
||||
| `/ok-to-perf` | Pull request | Trigger performance tests. | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr` |
|
||||
| `/make-me-laugh` | Issue or pull request | Posts a random joke | Users listed in the [bot](https://github.com/dapr/dapr/blob/master/.github/scripts/dapr_bot.js) | `dapr`, `components-contrib` |
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -64,6 +64,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:
|
||||
- Their own history
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue