[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 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 and personally identifiable information (PII) obfuscation.

daprdocs/content/en/concepts/dapr-services/scheduler.md

@@ -10,9 +10,9 @@ The Dapr Scheduler service is used to schedule different types of jobs, running
 - Actor reminder jobs (used by the actor reminders)
 - Actor reminder jobs created by the Workflow API (which uses actor reminders)
 
-From Dapr v1.15, the Scheduler service is used by default to schedule actor reminders as well as actor reminders for the Workflow API.
-
-There is no concept of a leader Scheduler instance. All Scheduler service replicas are considered peers. All receive jobs to be scheduled for execution and the jobs are allocated between the available Scheduler service replicas for load balancing of the trigger events.
+There is no concept of a leader Scheduler instance.
+All Scheduler service replicas are considered peers.
+All receive jobs to be scheduled for execution and the jobs are allocated between the available Scheduler service replicas for load balancing of the trigger events.
 
 The diagram below shows how the Scheduler service is used via the jobs API when called from your application. All the jobs that are tracked by the Scheduler service are stored in the Etcd database.
 
@@ -21,35 +21,17 @@ The diagram below shows how the Scheduler service is used via the jobs API when
 By default, Etcd is embedded in the Scheduler service, which means that the Scheduler service runs its own instance of Etcd.
 See [Scheduler service flags]({{% ref "#flag-tuning" %}}) for more information on how to configure the Scheduler service.
 
-## Actor Reminders
-
-Prior to Dapr v1.15, [actor reminders]({{% ref "actors-timers-reminders#actor-reminders" %}}) were run using the Placement service. Now, by default, the [`SchedulerReminders` feature flag]({{% ref "support-preview-features#current-preview-features" %}}) is set to `true`, and all new actor reminders you create are run using the Scheduler service to make them more scalable.
-
-When you deploy Dapr v1.15, any _existing_ actor reminders are automatically migrated from the Actor State Store to the Scheduler service as a one time operation for each actor type. Each replica will only migrate the reminders whose actor type and id are associated with that host. This means that only when all replicas implementing an actor type are upgraded to 1.15, will all the reminders associated with that type be migrated. There will be _no_ loss of reminder triggers during the migration. However, you can prevent this migration and keep the existing actor reminders running using the Actor State Store by setting the `SchedulerReminders` flag to `false` in the application configuration file for the actor type.
-
-To confirm that the migration was successful, check the Dapr sidecar logs for the following:
-
-```sh
-Running actor reminder migration from state store to scheduler
-```
-coupled with
-```sh
-Migrated X reminders from state store to scheduler successfully
-```
-or
-```sh
-Skipping migration, no missing scheduler reminders found
-```
-
 ## Job Locality
 
 ### Default Job Behavior
 
-By default, when the Scheduler service triggers jobs, they are sent back to a single replica for the same app ID that scheduled the job in a randomly load balanced manner. This provides basic load balancing across your application's replicas, which is suitable for most use cases where strict locality isn't required.
+When the Scheduler service triggers jobs, they are sent back to a single replica for the same app ID that scheduled the job in a randomly load balanced manner.
+This provides basic load balancing across your application's replicas, which is suitable for most use cases where strict locality isn't required.
 
 ### Using Actor Reminders for Perfect Locality
 
-For users who require perfect job locality (having jobs triggered on the exact same host that created them), actor reminders provide a solution. To enforce perfect locality for a job:
+For users who require perfect job locality (having jobs triggered on the exact same host that created them), actor reminders provide a solution.
+To enforce perfect locality for a job:
 
 1. Create an actor type with a random UUID that is unique to the specific replica
 2. Use this actor type to create an actor reminder
@@ -60,7 +42,7 @@ This approach ensures that the job will always be triggered on the same host whi
 
 ### Job Failure Policy and Staging Queue
 
-When the Scheduler service triggers a job and it has a client side error, the job is retried by default with a 1s interval and 3 maximum retries. 
+When the Scheduler service triggers a job and it has a client side error, the job is retried by default with a 1s interval and 3 maximum retries.
 
 For non-client side errors, for example, when a job cannot be sent to an available Dapr sidecar at trigger time, it is placed in a staging queue within the Scheduler service. Jobs remain in this queue until a suitable sidecar instance becomes available, at which point they are automatically sent to the appropriate Dapr sidecar instance.
 
@@ -191,16 +173,20 @@ dapr scheduler delete-all actor/MyActorType
 
 ### Backup and restore jobs
 
-Export all jobs to a file:
+In production environments, it's recommended to perform periodic backups of this data at an interval that aligns with your recovery point objectives.
+The Dapr CLI provides a command for exporting all Scheduler data to a specific binary file.
+Use the `-k` flag when running in Kubernetes mode.
 
-```bash
-dapr scheduler export -o backup.bin
+```shell
+dapr scheduler export --output-file scheduler-backup.db
+dapr scheduler export -k --output-file scheduler-backup.db
 ```
 
-Re-import jobs from a backup file:
+To restore data from a backup file:
 
-```bash
-dapr scheduler import -f backup.bin
+```shell
+dapr scheduler import --input-file scheduler-backup.db
+dapr scheduler import -k --input-file scheduler-backup.db
 ```
 
 ## Monitoring Scheduler's etcd Metrics
@@ -216,7 +202,6 @@ Fine tune the embedded etcd to your needs by [reviewing and configuring the Sche
 ## Disabling the Scheduler service
 
 If you are not using any features that require the Scheduler service (Jobs API, Actor Reminders, or Workflows), you can disable it by setting `global.scheduler.enabled=false`.
-
 For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{% ref kubernetes %}}).
 
 ## Flag tuning

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

@@ -10,7 +10,7 @@ A core tenet of the [virtual actor pattern](https://www.microsoft.com/research/p
 
 Reentrancy solves this by allowing requests from the same chain, or context, to re-enter into an already locked actor. This proves useful in scenarios where:
 - An actor wants to call a method on itself
-- Actors are used in workflows to perform work, then call back onto the coordinating actor. 
+- Actors are used in workflows to perform work, then call back onto the coordinating actor.
 
 Examples of chains that reentrancy allows are shown below:
 

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

@@ -8,13 +8,13 @@ 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
 
 Dapr actors are virtual, meaning that their lifetime is not tied to their in-memory representation. As a result, they do not need to be explicitly created or destroyed. The Dapr actor runtime automatically activates an actor the first time it receives a request for that actor ID. If an actor is not used for a period of time, the Dapr actor runtime garbage-collects the in-memory object. It will also maintain knowledge of the actor's existence should it need to be reactivated later.
 
-Invocation of actor methods, timers, and reminders reset the actor idle time. For example, a reminder firing keeps the actor active. 
+Invocation of actor methods, timers, and reminders reset the actor idle time. For example, a reminder firing keeps the actor active.
 - Actor reminders fire whether an actor is active or inactive. If fired for an inactive actor, it activates the actor first.
 - Actor timers firing reset the idle time; however, timers only fire while the actor is active.
 
@@ -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
 
@@ -101,4 +101,4 @@ The following example illustrates the above concepts. Consider an actor type tha
 
 - [Actors API reference]({{% ref actors_api %}})
 - [Actors overview]({{% ref actors-overview %}})
-- [How to: Use virtual actors in Dapr]({{% ref howto-actors %}})
+- [How to: Use virtual actors in Dapr]({{% ref howto-actors %}})

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

@@ -6,7 +6,7 @@ weight: 30
 description: Modify the default Dapr actor runtime configuration behavior
 ---
 
-You can modify the default Dapr actor runtime behavior using the following configuration parameters. 
+You can modify the default Dapr actor runtime behavior using the following configuration parameters.
 
 | Parameter | Description | Default |
 | --------- | ----------- | ------- |
@@ -16,7 +16,6 @@ You can modify the default Dapr actor runtime behavior using the following confi
 | `drainOngoingCallTimeout` | The duration when in the process of draining rebalanced actors. This specifies the timeout for the current active actor method to finish. If there is no current actor method call, this is ignored. | 60 seconds |
 | `drainRebalancedActors` | If true, Dapr will wait for `drainOngoingCallTimeout` duration to allow a current actor call to complete before trying to deactivate an actor. | true |
 | `reentrancy` (`ActorReentrancyConfig`) | Configure the reentrancy behavior for an actor. If not provided, reentrancy is disabled. | disabled, false |
-| `remindersStoragePartitions` | Configure the number of partitions for actor's reminders. If not provided, all reminders are saved as a single record in actor's state store. | 0 |
 | `entitiesConfig` | Configure each actor type individually with an array of configurations. Any entity specified in the individual entity configurations must also be specified in the top level `entities` field. | N/A |
 
 ## Examples
@@ -39,7 +38,6 @@ public void ConfigureServices(IServiceCollection services)
         options.ActorScanInterval = TimeSpan.FromSeconds(30);
         options.DrainOngoingCallTimeout = TimeSpan.FromSeconds(60);
         options.DrainRebalancedActors = true;
-        options.RemindersStoragePartitions = 7;
         options.ReentrancyConfig = new() { Enabled = false };
 
         // Add a configuration for a specific actor type.
@@ -81,7 +79,6 @@ const clientOptions = {
       enabled: true,
       maxStackDepth: 32,
     },
-    remindersStoragePartitions: 0,
   },
 };
 
@@ -112,7 +109,6 @@ ActorRuntime.set_actor_config(
         drain_ongoing_call_timeout=timedelta(minutes=1),
         drain_rebalanced_actors=True,
         reentrancy=ActorReentrancyConfig(enabled=False),
-        remindersStoragePartitions=7
     )
 )
 ```
@@ -134,7 +130,6 @@ ActorRuntime.getInstance().getConfig().setActorScanInterval(Duration.ofSeconds(3
 ActorRuntime.getInstance().getConfig().setDrainOngoingCallTimeout(Duration.ofSeconds(60));
 ActorRuntime.getInstance().getConfig().setDrainBalancedActors(true);
 ActorRuntime.getInstance().getConfig().setActorReentrancyConfig(false, null);
-ActorRuntime.getInstance().getConfig().setRemindersStoragePartitions(7);
 ```
 
 [See the documentation on writing actors with the Java SDK]({{% ref "java#actors" %}}).