Merge branch 'v1.14' into feature/update-kafka-pubsub-docs

daprdocs/content/en/_index.md

@@ -87,6 +87,13 @@ you tackle the challenges that come with building microservices and keeps your c
       <a href="{{< ref contributing >}}" class="stretched-link"></a>
     </div>
   </div>
+  <div class="card">
+    <div class="card-body">
+      <h5 class="card-title"><b>Roadmap</b></h5>
+      <p class="card-text">Learn about Dapr's roadmap and change process.</p>
+      <a href="{{< ref roadmap.md >}}" class="stretched-link"></a>
+    </div>
+  </div>
 </div>
 
 

daprdocs/content/en/concepts/overview.md

@@ -108,7 +108,7 @@ Deploying and running a Dapr-enabled application into your Kubernetes cluster is
 
 ### Clusters of physical or virtual machines
 
-The Dapr control plane services can be deployed in high availability (HA) mode to clusters of physical or virtual machines in production. In the diagram below, the Actor `Placement` and security `Sentry` services are started on three different VMs to provide HA control plane. In order to provide name resolution using DNS for the applications running in the cluster, Dapr uses [Hashicorp Consul service]({{< ref setup-nr-consul >}}), also running in HA mode.  
+The Dapr control plane services can be deployed in high availability (HA) mode to clusters of physical or virtual machines in production. In the diagram below, the Actor `Placement` and security `Sentry` services are started on three different VMs to provide HA control plane. In order to provide name resolution using DNS for the applications running in the cluster, Dapr uses multicast DNS by default, but can also optionally support [Hashicorp Consul service]({{< ref setup-nr-consul >}}).  
 
 <img src="/images/overview-vms-hosting.png" width=1200 alt="Architecture diagram of Dapr control plane and Consul deployed to VMs in high availability mode">
 

daprdocs/content/en/contributing/contributing-overview.md

@@ -18,7 +18,7 @@ See the [Dapr community repository](https://github.com/dapr/community) for more
 
 1. **Docs**: This [repository](https://github.com/dapr/docs) contains the documentation for Dapr. You can contribute by updating existing documentation, fixing errors, or adding new content to improve user experience and clarity. Please see the specific guidelines for [docs contributions]({{< ref contributing-docs >}}).
 
-2. **Quickstarts**: The Quickstarts [repository](https://github.com/dapr/quickstarts) provides simple, step-by-step guides to help users get started with Dapr quickly. Contributions in this repository involve creating new quickstarts, improving existing ones, or ensuring they stay up-to-date with the latest features.
+2. **Quickstarts**: The Quickstarts [repository](https://github.com/dapr/quickstarts) provides simple, step-by-step guides to help users get started with Dapr quickly. [Contributions in this repository](https://github.com/dapr/quickstarts/blob/master/CONTRIBUTING.md) involve creating new quickstarts, improving existing ones, or ensuring they stay up-to-date with the latest features.
 
 3. **Runtime**: The Dapr runtime [repository](https://github.com/dapr/dapr) houses the core runtime components. Here, you can contribute by fixing bugs, optimizing performance, implementing new features, or enhancing existing ones.
 

daprdocs/content/en/contributing/daprbot.md

@@ -2,7 +2,7 @@
 type: docs
 title: "Dapr bot reference"
 linkTitle: "Dapr bot"
-weight: 15
+weight: 70
 description: "List of Dapr bot capabilities."
 ---
 

daprdocs/content/en/contributing/docs-contrib/contributing-docs.md

@@ -41,15 +41,18 @@ Style and tone conventions should be followed throughout all Dapr documentation
 
 ## Diagrams and images
 
-Diagrams and images are invaluable visual aids for documentation pages. Diagrams are kept in a [Dapr Diagrams Deck](https://github.com/dapr/docs/tree/v1.11/daprdocs/static/presentations), which includes guidance on style and icons. 
+Diagrams and images are invaluable visual aids for documentation pages. Use the diagram style and icons in the [Dapr Diagrams template deck](https://github.com/dapr/docs/tree/v1.14/daprdocs/static/presentations). 
 
-As you create diagrams for your documentation:
+The process for creating diagrams for your documentation:
 
-- Save them as high-res PNG files into the [images folder](https://github.com/dapr/docs/tree/v1.11/daprdocs/static/images).
-- Name your PNG files using the convention of a concept or building block so that they are grouped.
+1. Download the [Dapr Diagrams template deck](https://github.com/dapr/docs/tree/v1.14/daprdocs/static/presentations) to use the icons and colors.
+1. Add a new slide and create your diagram. 
+1. Screen capture the diagram as high-res PNG file and save in the [images folder](https://github.com/dapr/docs/tree/v1.14/daprdocs/static/images).
+1. Name your PNG files using the convention of a concept or building block so that they are grouped.
   - For example: `service-invocation-overview.png`. 
   - For more information on calling out images using shortcode, see the [Images guidance](#images) section below.
-- Add the diagram to the correct section in the `Dapr-Diagrams.pptx` deck so that they can be amended and updated during routine refresh.
+1. Add the diagram to the appropriate section in your documentation using the HTML `<image>` tag.
+1. In your PR, comment the diagram slide (not the screen capture) so it can be reviewed and added to the diagram deck by maintainers.
 
 ## Contributing a new docs page
 

daprdocs/content/en/developing-applications/building-blocks/jobs/howto-schedule-and-handle-triggered-jobs.md

@@ -94,6 +94,75 @@ In this example, at trigger time, which is `@every 1s` according to the `Schedul
 
 At the trigger time, the `prodDBBackupHandler` function is called, executing the desired business logic for this job at trigger time. For example:
 
+#### HTTP
+
+When you create a job using Dapr's Jobs API, Dapr will automatically assume there is an endpoint available at 
+`/job/<job-name>`. For instance, if you schedule a job named `test`, Dapr expects your application to listen for job 
+events at `/job/test`. Ensure your application has a handler set up for this endpoint to process the job when it is 
+triggered. For example:
+
+*Note: The following example is in Go but applies to any programming language.*
+
+```go
+
+func main() {
+    ...
+    http.HandleFunc("/job/", handleJob)
+	http.HandleFunc("/job/<job-name>", specificJob)
+    ...
+}
+
+func specificJob(w http.ResponseWriter, r *http.Request) {
+    // Handle specific triggered job
+}
+
+func handleJob(w http.ResponseWriter, r *http.Request) {
+    // Handle the triggered jobs
+}
+```
+
+#### gRPC
+
+When a job reaches its scheduled trigger time, the triggered job is sent back to the application via the following 
+callback function:
+
+*Note: The following example is in Go but applies to any programming language with gRPC support.*
+
+```go
+import rtv1 "github.com/dapr/dapr/pkg/proto/runtime/v1"
+...
+func (s *JobService) OnJobEventAlpha1(ctx context.Context, in *rtv1.JobEventRequest) (*rtv1.JobEventResponse, error) {
+    // Handle the triggered job
+}
+```
+
+This function processes the triggered jobs within the context of your gRPC server. When you set up the server, ensure that 
+you register the callback server, which will invoke this function when a job is triggered:
+
+```go
+...
+js := &JobService{}
+rtv1.RegisterAppCallbackAlphaServer(server, js)
+```
+
+In this setup, you have full control over how triggered jobs are received and processed, as they are routed directly 
+through this gRPC method.
+
+#### SDKs
+
+For SDK users, handling triggered jobs is simpler. When a job is triggered, Dapr will automatically route the job to the 
+event handler you set up during the server initialization. For example, in Go, you'd register the event handler like this:
+
+```go
+...
+if err = server.AddJobEventHandler("prod-db-backup", prodDBBackupHandler); err != nil {
+    log.Fatalf("failed to register job event handler: %v", err)
+}
+```
+
+Dapr takes care of the underlying routing. When the job is triggered, your `prodDBBackupHandler` function is called with
+the triggered job data. Here’s an example of handling the triggered job:
+
 ```go
 // ...
 
@@ -144,4 +213,4 @@ dapr run --app-id=distributed-scheduler \
 ## Next steps
 
 - [Learn more about the Scheduler control plane service]({{< ref "concepts/dapr-services/scheduler.md" >}})
-- [Jobs API reference]({{< ref jobs_api.md >}})
+- [Jobs API reference]({{< ref jobs_api.md >}})

daprdocs/content/en/developing-applications/building-blocks/pubsub/subscription-methods.md

@@ -37,17 +37,16 @@ metadata:
 spec:
   topic: orders
   routes:
-    default: /checkout
+    default: /orders
   pubsubname: pubsub
 scopes:
 - orderprocessing
-- checkout
 ```
 
 Here the subscription called `order`: 
 - Uses the pub/sub component called `pubsub` to subscribes to the topic called `orders`.
-- Sets the `route` field to send all topic messages to the `/checkout` endpoint in the app.
-- Sets `scopes` field to scope this subscription for access only by apps with IDs `orderprocessing` and `checkout`.
+- Sets the `route` field to send all topic messages to the `/orders` endpoint in the app.
+- Sets `scopes` field to scope this subscription for access only by apps with ID `orderprocessing`.
 
 When running Dapr, set the YAML component file path to point Dapr to the component.
 
@@ -113,7 +112,7 @@ In your application code, subscribe to the topic specified in the Dapr pub/sub c
 
 ```csharp
  //Subscribe to a topic 
-[HttpPost("checkout")]
+[HttpPost("orders")]
 public void getCheckout([FromBody] int orderId)
 {
     Console.WriteLine("Subscriber received : " + orderId);
@@ -128,7 +127,7 @@ public void getCheckout([FromBody] int orderId)
 import io.dapr.client.domain.CloudEvent;
 
  //Subscribe to a topic
-@PostMapping(path = "/checkout")
+@PostMapping(path = "/orders")
 public Mono<Void> getCheckout(@RequestBody(required = false) CloudEvent<String> cloudEvent) {
     return Mono.fromRunnable(() -> {
         try {
@@ -146,7 +145,7 @@ public Mono<Void> getCheckout(@RequestBody(required = false) CloudEvent<String>
 from cloudevents.sdk.event import v1
 
 #Subscribe to a topic 
-@app.route('/checkout', methods=['POST'])
+@app.route('/orders', methods=['POST'])
 def checkout(event: v1.Event) -> None:
     data = json.loads(event.Data())
     logging.info('Subscriber received: ' + str(data))
@@ -163,7 +162,7 @@ const app = express()
 app.use(bodyParser.json({ type: 'application/*+json' }));
 
 // listen to the declarative route
-app.post('/checkout', (req, res) => {
+app.post('/orders', (req, res) => {
   console.log(req.body);
   res.sendStatus(200);
 });
@@ -178,7 +177,7 @@ app.post('/checkout', (req, res) => {
 var sub = &common.Subscription{
 	PubsubName: "pubsub",
 	Topic:      "orders",
-	Route:      "/checkout",
+	Route:      "/orders",
 }
 
 func eventHandler(ctx context.Context, e *common.TopicEvent) (retry bool, err error) {
@@ -191,7 +190,7 @@ func eventHandler(ctx context.Context, e *common.TopicEvent) (retry bool, err er
 
 {{< /tabs >}}
 
-The `/checkout` endpoint matches the `route` defined in the subscriptions and this is where Dapr sends all topic messages to.
+The `/orders` endpoint matches the `route` defined in the subscriptions and this is where Dapr sends all topic messages to.
 
 ### Streaming subscriptions
 
@@ -325,7 +324,7 @@ In the example below, you define the values found in the [declarative YAML subsc
 
 ```csharp
 [Topic("pubsub", "orders")]
-[HttpPost("/checkout")]
+[HttpPost("/orders")]
 public async Task<ActionResult<Order>>Checkout(Order order, [FromServices] DaprClient daprClient)
 {
     // Logic
@@ -337,7 +336,7 @@ or
 
 ```csharp
 // Dapr subscription in [Topic] routes orders topic to this route
-app.MapPost("/checkout", [Topic("pubsub", "orders")] (Order order) => {
+app.MapPost("/orders", [Topic("pubsub", "orders")] (Order order) => {
     Console.WriteLine("Subscriber received : " + order);
     return Results.Ok(order);
 });
@@ -359,7 +358,7 @@ app.UseEndpoints(endpoints =>
 ```java
 private static final ObjectMapper OBJECT_MAPPER = new ObjectMapper();
 
-@Topic(name = "checkout", pubsubName = "pubsub")
+@Topic(name = "orders", pubsubName = "pubsub")
 @PostMapping(path = "/orders")
 public Mono<Void> handleMessage(@RequestBody(required = false) CloudEvent<String> cloudEvent) {
   return Mono.fromRunnable(() -> {
@@ -370,6 +369,7 @@ public Mono<Void> handleMessage(@RequestBody(required = false) CloudEvent<String
       throw new RuntimeException(e);
     }
   });
+}
 ```
 
 {{% /codetab %}}
@@ -382,7 +382,7 @@ def subscribe():
     subscriptions = [
       {
         'pubsubname': 'pubsub',
-        'topic': 'checkout',
+        'topic': 'orders',
         'routes': {
           'rules': [
             {
@@ -418,7 +418,7 @@ app.get('/dapr/subscribe', (req, res) => {
   res.json([
     {
       pubsubname: "pubsub",
-      topic: "checkout",
+      topic: "orders",
       routes: {
         rules: [
           {
@@ -480,7 +480,7 @@ func configureSubscribeHandler(w http.ResponseWriter, _ *http.Request) {
 	t := []subscription{
 		{
 			PubsubName: "pubsub",
-			Topic:      "checkout",
+			Topic:      "orders",
 			Routes: routes{
 				Rules: []rule{
 					{

daprdocs/content/en/developing-applications/building-blocks/state-management/howto-get-save-state.md

@@ -10,8 +10,6 @@ State management is one of the most common needs of any new, legacy, monolith, o
 
 In this guide, you'll learn the basics of using the key/value state API to allow an application to save, get, and delete state.
 
-## Example
-
 The code example below _loosely_ describes an application that processes orders with an order processing service which has a Dapr sidecar. The order processing service uses Dapr to store state in a Redis state store.
 
 <img src="/images/building-block-state-management-example.png" width=1000 alt="Diagram showing state management of example service">
@@ -554,7 +552,7 @@ namespace EventService
             string DAPR_STORE_NAME = "statestore";
             //Using Dapr SDK to retrieve multiple states
             using var client = new DaprClientBuilder().Build();
-            IReadOnlyList<BulkStateItem> mulitpleStateResult = await client.GetBulkStateAsync(DAPR_STORE_NAME, new List<string> { "order_1", "order_2" }, parallelism: 1);
+            IReadOnlyList<BulkStateItem> multipleStateResult = await client.GetBulkStateAsync(DAPR_STORE_NAME, new List<string> { "order_1", "order_2" }, parallelism: 1);
         }
     }
 }

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

@@ -135,7 +135,7 @@ Because workflow retry policies are configured in code, the exact developer expe
 | --- | --- |
 | **Maximum number of attempts** | The maximum number of times to execute the activity or child workflow. |
 | **First retry interval** | The amount of time to wait before the first retry. |
-| **Backoff coefficient** | The amount of time to wait before each subsequent retry. |
+| **Backoff coefficient** | The coefficient used to determine the rate of increase of back-off. For example a coefficient of 2 doubles the wait of each subsequent retry. |
 | **Maximum retry interval** | The maximum amount of time to wait before each subsequent retry. |
 | **Retry timeout** | The overall timeout for retries, regardless of any configured max number of attempts. |
 

daprdocs/content/en/getting-started/quickstarts/workflow-quickstart.md

@@ -10,6 +10,10 @@ description: Get started with the Dapr Workflow building block
 Dapr Workflow is currently in beta. [See known limitations for {{% dapr-latest-version cli="true" %}}]({{< ref "workflow-overview.md#limitations" >}}).
 {{% /alert %}}
 
+{{% alert title="Note" color="primary" %}}
+Redis is currently used as the state store component for Workflows in the Quickstarts. However, Redis does not support transaction rollbacks and should not be used in production as an actor state store.
+{{% /alert %}}
+
 Let's take a look at the Dapr [Workflow building block]({{< ref workflow-overview.md >}}). In this Quickstart, you'll create a simple console application to demonstrate Dapr's workflow programming model and the workflow management APIs.
 
 In this guide, you'll:
@@ -1356,4 +1360,4 @@ Join the discussion in our [discord channel](https://discord.com/channels/778680
 - Walk through a more in-depth [.NET SDK example workflow](https://github.com/dapr/dotnet-sdk/tree/master/examples/Workflow)
 - Learn more about [Workflow as a Dapr building block]({{< ref workflow-overview >}})
 
-{{< button text="Explore Dapr tutorials  >>" page="getting-started/tutorials/_index.md" >}}
+{{< button text="Explore Dapr tutorials  >>" page="getting-started/tutorials/_index.md" >}}

daprdocs/content/en/operations/support/support-release-policy.md

@@ -24,7 +24,7 @@ A supported release means:
 
 From the 1.8.0 release onwards three (3) versions of Dapr are supported; the current and previous two (2) versions. Typically these are `MINOR`release updates. This means that there is a rolling window that moves forward for supported releases and it is your operational responsibility to remain up to date with these supported versions. If you have an older version of Dapr you may have to do intermediate upgrades to get to a supported version.
 
-There will be at least 6 weeks between major.minor version releases giving users a 12 week (3 month) rolling window for upgrading.
+There will be at least 13 weeks (3 months) between major.minor version releases giving users at least a 9 month rolling window for upgrading from a non-supported version. For more details on the release process read [release cycle and cadence](https://github.com/dapr/community/blob/master/release-process.md)
 
 Patch support is for supported versions (current and previous).