From 5c110e522dc892f7de6998b302490ac7547303a3 Mon Sep 17 00:00:00 2001 From: Enis Necipoglu Date: Tue, 30 Jun 2026 07:54:35 +0300 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../2026-06-28-working-with-dapr-workflows/POST.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/en/Community-Articles/2026-06-28-working-with-dapr-workflows/POST.md b/docs/en/Community-Articles/2026-06-28-working-with-dapr-workflows/POST.md index ee885f0ce2..4a97b9d7cb 100644 --- a/docs/en/Community-Articles/2026-06-28-working-with-dapr-workflows/POST.md +++ b/docs/en/Community-Articles/2026-06-28-working-with-dapr-workflows/POST.md @@ -18,7 +18,7 @@ You define a [**workflow**](https://docs.dapr.io/developing-applications/buildin > **This is orchestration rather than choreography:** one place drives the process, instead of services reacting to each other's events. The definitions live in your app, but the engine that executes them runs in the Dapr sidecar next to it. -![mermaid1](./mermaid1.png) +![Dapr workflow execution architecture diagram](./mermaid1.png) The key idea is **durable execution**. Dapr records every step to a state store, so the workflow can be replayed from history at any time. A crash, a deployment, or a scale-out event doesn't lose progress, and a workflow can run for seconds or for months. @@ -231,7 +231,7 @@ Each activity is isolated, so Dapr can retry a failed one without re-running the Here's the shape of the process we just wrote: -![mermaid2](./mermaid2.png) +![Order processing workflow flowchart](./mermaid2.png) ## Register the Workflow