[1.17] Workflow/CLI/Reminder Documentation

daprdocs/content/en/concepts/building-blocks-concept.md

@@ -31,4 +31,4 @@ Dapr provides the following building blocks:
 | [**Distributed lock**]({{% ref "distributed-lock-api-overview" %}}) | `/v1.0-alpha1/lock` | The distributed lock API enables you to take a lock on a resource so that multiple instances of an application can access the resource without conflicts and provide consistency guarantees.  
 | [**Cryptography**]({{% ref "cryptography-overview" %}}) | `/v1.0-alpha1/crypto` | The Cryptography API enables you to perform cryptographic operations, such as encrypting and decrypting messages, without exposing keys to your application.
 | [**Jobs**]({{% ref "jobs-overview" %}}) | `/v1.0-alpha1/jobs` | The Jobs API enables you to schedule and orchestrate jobs. Example scenarios include: <ul><li>Schedule batch processing jobs to run every business day</li><li>Schedule various maintenance scripts to perform clean-ups</li><li>Schedule ETL jobs to run at specific times (hourly, daily) to fetch new data, process it, and update the data warehouse with the latest information.</li></ul>
-| [**Conversation**]({{% ref "conversation-overview" %}}) | `/v1.0-alpha2/conversation` | The Conversation API enables you to supply prompts to converse with different large language models (LLMs) and includes features such as prompt caching, response formatting, usage metrics, and personally identifiable information (PII) obfuscation.
+| [**Conversation**]({{% ref "conversation-overview" %}}) | `/v1.0-alpha2/conversation` | The Conversation API enables you to supply prompts to converse with different large language models (LLMs) and includes features such as prompt caching, response formatting, usage metrics, and personally identifiable information (PII) obfuscation.

daprdocs/content/en/developing-applications/building-blocks/actors/actors-features-concepts.md

@@ -8,7 +8,7 @@ aliases:
   - "/developing-applications/building-blocks/actors/actors-background"
 ---
 
-Now that you've learned about the [actor building block]({{% ref "actors-overview" %}}) at a high level, let's deep dive into the features and concepts included with actors in Dapr. 
+Now that you've learned about the [actor building block]({{% ref "actors-overview" %}}) at a high level, let's deep dive into the features and concepts included with actors in Dapr.
 
 ## Actor lifetime
 
@@ -28,7 +28,7 @@ An actor is automatically activated (causing an actor object to be constructed)
 
 To provide scalability and reliability, actors instances are distributed throughout the cluster and Dapr automatically migrates them from failed nodes to healthy ones as required.
 
-Actors are distributed across the instances of the actor service, and those instance are distributed across the nodes in a cluster. Each service instance contains a set of actors for a given actor type.
+Actors are distributed across the instances of the actor service, and those instances are distributed across the nodes in a cluster. Each service instance contains a set of actors for a given actor type.
 
 ### Actor placement service
 

daprdocs/content/en/developing-applications/building-blocks/actors/actors-timers-reminders.md

@@ -14,7 +14,10 @@ The functionality of timers and reminders is very similar. The main difference i
 
 This distinction allows users to trade off between light-weight but stateless timers vs. more resource-demanding but stateful reminders.
 
-The scheduling configuration of timers and reminders is identical, as summarized below:
+The scheduling configuration of timers and reminders is summarized below:
+
+---
+`data` is an optional parameter that contains the data passed to the reminder callback method when invoked
 
 ---
 `dueTime` is an optional parameter that sets time at which or time interval before the callback is invoked for the first time. If `dueTime` is omitted, the callback is invoked immediately after timer/reminder registration.
@@ -32,7 +35,6 @@ Supported formats:
 - time.Duration format (Sub-second precision is supported when using duration values), e.g. `2h30m`, `500ms`
 - [ISO 8601 duration](https://en.wikipedia.org/wiki/ISO_8601#Durations) format, e.g. `PT2H30M`, `R5/PT1M30S`
 
-Note: Actual trigger resolution may vary by runtime and environment.
 ---
 `ttl` is an optional parameter that sets time at which or time interval after which the timer/reminder will be expired and deleted. If `ttl` is omitted, no restrictions are applied.
 
@@ -42,13 +44,34 @@ Supported formats:
 * [ISO 8601 duration](https://en.wikipedia.org/wiki/ISO_8601#Durations) format. Example: `PT2H30M`
 
 ---
+Only available on **reminders**.
+
+`overwrite` is an optional boolean parameter that indicates whether to overwrite an existing reminder with the same name.
+If `overwrite` is set to `true`, any existing reminder with the same name will be replaced by the new configuration.
+If `overwrite` is set to `false` or omitted, and a reminder with the same name already exists, the operation will fail with a already exists error.
+Note that overwriting an existing reminder will reset its an error.state, including the number of invocations and the next trigger time, just like creating a new reminder.
+
+---
+Only available on **reminders**.
+
+`failurePolicy` is an optional parameter that defines the behavior when a reminder invocation fails.
+The supported failure policies are:
+- `drop`: The failed invocation is dropped, and the reminder continues with the next scheduled invocation, as if the failure did not occur.
+- `constant`: The reminder will retry the failed invocation a specified number of times with a fixed interval between each attempt.
+  * `interval`: The time interval between each retry attempt. If not specified, the interval becomes "0s", meaning retries is attempted immediately.
+  * `maxRetries`: The maximum number of retry attempts. If not specified, the invocation will be retried indefinitely at the specified interval until it succeeds.
+
+If no failure policy is specified, the default failure policy of 3 retries with an interval of 1 second will be applied.
+
+---
+
 The actor runtime validates correctness of the scheduling configuration and returns error on invalid input.
 
-When you specify both the number of repetitions in `period` as well as `ttl`, the timer/reminder will be stopped when either condition is met.
+When you specify both the number of repetitions in `period` as well as `ttl`, the timer/reminder will be stopped when either condition is met, whichever occurs first.
 
 ## Actor timers
 
-You can register a callback on actor to be executed based on a timer.
+You can register a callback on the actor to be executed based on a timer.
 
 The Dapr actor runtime ensures that the callback methods respect the turn-based concurrency guarantees. This means that no other actor methods or timer/reminder callbacks will be in progress until this callback completes execution.
 
@@ -108,15 +131,15 @@ Refer [api spec]({{% ref "actors_api#invoke-timer" %}}) for more details.
 
 ## Actor reminders
 
-Reminders are a mechanism to trigger *persistent* callbacks on an actor at specified times. Their functionality is similar to timers. But unlike timers, reminders are triggered under all circumstances until the actor explicitly unregisters them or the actor is explicitly deleted or the number in invocations is exhausted. Specifically, reminders are triggered across actor deactivations and failovers because the Dapr actor runtime persists the information about the actors' reminders using Dapr actor state provider.
+Reminders are a mechanism to trigger *persistent* callbacks on an actor at specified times. Their functionality is similar to timers. But unlike timers, reminders are triggered under all circumstances until the actor explicitly unregisters them or the number in invocations is exhausted. Specifically, reminders are triggered across actor deactivations and failovers because the Dapr actor runtime persists the information about the actors' reminders using the Dapr [Scheduler service]({{% ref scheduler.md %}}).
 
 You can create a persistent reminder for an actor by calling the HTTP/gRPC request to Dapr as shown below, or via Dapr SDK.
 
 ```md
 POST/PUT http://localhost:3500/v1.0/actors/<actorType>/<actorId>/reminders/<name>
 ```
 
-The request structure for reminders is identical to those of actors. Please refer to the [actor timers examples]({{% ref "#actor-timers" %}}).
+Unlike timers, reminders support an `overwrite` option that allows you to replace an existing reminder with the same name, as well as a `failurePolicy` option that defines the behavior when a reminder invocation fails.
 
 ### Retrieve actor reminder
 
@@ -134,20 +157,18 @@ You can remove the actor reminder by calling
 DELETE http://localhost:3500/v1.0/actors/<actorType>/<actorId>/reminders/<name>
 ```
 
-If an actor reminder is triggered and the app does not return a 2** code to the runtime (for example, because of a connection issue),
-actor reminders will be retried up to three times with a backoff interval of one second between each attempt. There may be 
-additional retries attempted in accordance with any optionally applied [actor resiliency policy]({{% ref "override-default-retries" %}}). 
+If an actor reminder is triggered and the app does not return a 2** code to the runtime (for example, because of a connection issue), actor reminders will be retried according to its failure policy, which by default is three times with a backoff interval of one second between each attempt.
+There may be additional retries attempted in accordance with any optionally applied [actor resiliency policy]({{% ref "override-default-retries" %}}).
 
 Refer [api spec]({{% ref "actors_api#invoke-reminder" %}}) for more details.
 
 ## Error handling
 
-When an actor's method completes successfully, the runtime will continue to invoke the method at the specified timer or reminder schedule. However, if the method throws an exception, the runtime catches it and logs the error message in the Dapr sidecar logs, without retrying.
-
-To allow actors to recover from failures and retry after a crash or restart, you can persist an actor's state by configuring a state store, like Redis or Azure Cosmos DB. 
+When an actor's method completes successfully, the runtime will continue to invoke the method at the specified timer or reminder schedule.
+To allow actors to recover from failures and retry after a crash or restart, you can persist an actor's state by configuring a state store, like Redis or Azure Cosmos DB.
 
 If an invocation of the method fails, the timer is not removed. Timers are only removed when:
-- The sidecar crashes
+- The sidecar terminates
 - The executions run out
 - You delete it explicitly
 
@@ -225,6 +246,19 @@ Delete all reminders for a specific actor instance:
 dapr scheduler delete-all actor/MyActorType/actorid1
 ```
 
+Delete all reminders for a specific actor type:
+
+```bash
+dapr scheduler delete-all actor/MyActorType
+```
+
+Delete all reminders
+
+```bash
+dapr scheduler delete-all actor
+```
+
+
 #### Backup and restore reminders
 
 Export all reminders:

daprdocs/content/en/developing-applications/building-blocks/actors/howto-actors.md

@@ -28,7 +28,7 @@ Alternatively, you can use [Dapr SDKs to use actors]({{% ref "developing-applica
 
 You can interact with Dapr via HTTP/gRPC endpoints to save state reliably using the Dapr actor state management capabaility.
 
-To use actors, your state store must support multi-item transactions. This means your state store component must implement the `TransactionalStore` interface. 
+To use actors, your state store must support multi-item transactions. This means your state store component must implement the `TransactionalStore` interface.
 
 [See the list of components that support transactions/actors]({{% ref supported-state-stores %}}). Only a single state store component can be used as the state store for all actors.
 
@@ -40,4 +40,4 @@ To use actors, your state store must support multi-item transactions. This means
 
 - Refer to the [Dapr SDK documentation and examples]({{% ref "developing-applications/sdks/_index.md#sdk-languages" %}}).
 - [Actors API reference]({{% ref actors_api %}})
-- [Actors overview]({{% ref actors-overview %}})
+- [Actors overview]({{% ref actors-overview %}})

daprdocs/content/en/developing-applications/building-blocks/workflow/howto-author-workflow.md

@@ -1173,12 +1173,12 @@ dapr workflow run hello_world_wf --app-id workflow-app --input 'hello world' --i
 
 #### Check the workflow status
 ```bash
-dapr workflow list --app-id workflow-app --connection-string=redis://127.0.0.1:6379 -o wide
+dapr workflow list --app-id workflow-app -o wide
 ```
 
 #### Check completed workflows
 ```bash
-dapr workflow list --app-id workflow-app --connection-string=redis://127.0.0.1:6379 --filter-status COMPLETED -o wide
+dapr workflow list --app-id workflow-app --filter-status COMPLETED -o wide
 ```
 
 #### View workflow history
@@ -1208,7 +1208,7 @@ dapr workflow run sequence --app-id workflow-app --input 'hello world' --instanc
 
 #### Check the workflow status
 ```bash
-dapr workflow list --app-id workflow-app --connection-string=redis://127.0.0.1:6379 -o wide
+dapr workflow list --app-id workflow-app -o wide
 ```
 
 #### Raise the waiting external event
@@ -1218,7 +1218,7 @@ dapr workflow raise-event --app-id workflow-app test-run/businessEvent
 
 #### Check completed workflows
 ```bash
-dapr workflow list --app-id workflow-app --connection-string=redis://127.0.0.1:6379 --filter-status COMPLETED -o wide
+dapr workflow list --app-id workflow-app --filter-status COMPLETED -o wide
 ```
 
 #### View workflow history
@@ -1248,7 +1248,7 @@ dapr workflow run OrderProcessingWorkflow --app-id workflow-app  --instance-id t
 
 #### Check the workflow status
 ```bash
-dapr workflow list --app-id workflow-app --connection-string=redis://127.0.0.1:6379 -o wide
+dapr workflow list --app-id workflow-app -o wide
 ```
 
 #### Raise the waiting external event
@@ -1258,7 +1258,7 @@ dapr workflow raise-event --app-id workflow-app test-run/incoming-purchase-order
 
 #### Check completed workflows
 ```bash
-dapr workflow list --app-id workflow-app --connection-string=redis://127.0.0.1:6379 --filter-status COMPLETED -o wide
+dapr workflow list --app-id workflow-app --filter-status COMPLETED -o wide
 ```
 
 #### View workflow history
@@ -1289,7 +1289,7 @@ dapr workflow run DemoWorkflow --app-id workflow-app  --instance-id test-run --i
 
 #### Check the workflow status
 ```bash
-dapr workflow list --app-id workflow-app --connection-string=redis://127.0.0.1:6379 -o wide
+dapr workflow list --app-id workflow-app -o wide
 ```
 
 #### Raise the waiting external event
@@ -1302,7 +1302,7 @@ dapr workflow raise-event --app-id workflow-app test-run/event3 --input 'TestEve
 
 #### Check completed workflows
 ```bash
-dapr workflow list --app-id workflow-app --connection-string=redis://127.0.0.1:6379 --filter-status COMPLETED -o wide
+dapr workflow list --app-id workflow-app --filter-status COMPLETED -o wide
 ```
 
 #### View workflow history
@@ -1332,7 +1332,7 @@ dapr workflow run BusinessWorkflow --app-id workflow-app --input '1' --instance-
 
 #### Check the workflow status
 ```bash
-dapr workflow list --app-id workflow-app --connection-string=redis://127.0.0.1:6379 -o wide
+dapr workflow list --app-id workflow-app -o wide
 ```
 
 #### Raise the waiting external event
@@ -1342,7 +1342,7 @@ dapr workflow raise-event --app-id workflow-app test-run/businessEvent
 
 #### Check completed workflows
 ```bash
-dapr workflow list --app-id workflow-app --connection-string=redis://127.0.0.1:6379 --filter-status COMPLETED -o wide
+dapr workflow list --app-id workflow-app --filter-status COMPLETED -o wide
 ```
 
 #### View workflow history
@@ -1399,7 +1399,6 @@ Now that you've authored a workflow, learn how to manage it.
 
 ## Related links
 - [Workflow overview]({{% ref workflow-overview.md %}})
-- [Workflow API reference]({{% ref workflow_api.md %}})
 - Try out the full SDK examples:
   - [Python example](https://github.com/dapr/python-sdk/tree/master/examples/demo_workflow)
   - [JavaScript example](https://github.com/dapr/js-sdk/tree/main/examples/workflow)