From c6395bd29f829b91cc72f07d6ccc4815d04134e8 Mon Sep 17 00:00:00 2001 From: pittu sharma Date: Mon, 23 Mar 2026 18:58:03 +0530 Subject: [PATCH 1/3] Update Maintainer Guide with latest CLI commands and release steps Signed-off-by: pittu sharma --- .../docs-contrib/maintainer-guide.md | 35 ++----------------- 1 file changed, 2 insertions(+), 33 deletions(-) diff --git a/daprdocs/content/en/contributing/docs-contrib/maintainer-guide.md b/daprdocs/content/en/contributing/docs-contrib/maintainer-guide.md index 7c72665b2f0..04b2a6a90ec 100644 --- a/daprdocs/content/en/contributing/docs-contrib/maintainer-guide.md +++ b/daprdocs/content/en/contributing/docs-contrib/maintainer-guide.md @@ -313,7 +313,7 @@ Deploy a new Azure Static Web App for the future Dapr release. For this example, 1. Log into Azure Developer CLI (`azd`) using the Dapr Azure subscription. ```bash - azd login + azd auth login ``` 1. In the browser prompt, verify you're logging in as Dapr and complete the login. @@ -374,38 +374,7 @@ You can repeat these steps for any preview versions. 1. Merge the PR from `release_v1.0` to `v1.0`. Delete the release/v1.0 branch. 1. Merge the PR from `release_v1.1` to `v1.1`. Delete the release/v1.1 branch. 1. Merge the PR from `release_v1.2` to `v1.2`. Delete the release/v1.2 branch. +1. In the GitHub UI **Settings > General**, update the **Default branch** to the latest version (e.g. `v1.1`). Congrats on the new docs release! 🚀 🎉 🎈 -## Pull in SDK doc updates - -SDK docs live in each of the SDK repos. Changes made to the SDK docs are pushed to the relevant SDK repo. For example, to update the Go SDK docs, you push changes to the `dapr/go-sdk` repo. Until you pull the latest `dapr/go-sdk` commit into the `dapr/docs` current version branch, your Go SDK docs updates won't be reflected on the Dapr docs site. - -To bring updates to the SDK docs live to the Dapr docs site, you need to perform a straightforward `git pull`. This example refers to the Go SDK, but applies to all SDKs. - -1. Pull the latest upstream into your local `dapr/docs` version branch. - -1. Change into the root of the `dapr/docs` directory. - -1. Change into the Go SDK repo. This command takes you out of the `dapr/docs` context and into the `dapr/go-sdk` context. - - ```bash - cd sdkdocs/go - ``` - -1. Switch to the `main` branch in `dapr/go-sdk`. - - ```bash - git checkout main - ``` - -1. Pull the latest Go SDK commit. - - ```bash - git pull upstream main - ``` - -1. Change into the `dapr/docs` context to commit, push, and create a PR. - -## Next steps - From 4fc9b4e6208e603f65cdfad296643322a3b02358 Mon Sep 17 00:00:00 2001 From: pittu sharma Date: Mon, 6 Apr 2026 23:44:37 +0530 Subject: [PATCH 2/3] Fix duplicate archived_version mapping key in hugo.yaml (#5100) Signed-off-by: pittu sharma --- hugo.yaml | 5 ----- 1 file changed, 5 deletions(-) diff --git a/hugo.yaml b/hugo.yaml index 73414832ed9..c2404885814 100644 --- a/hugo.yaml +++ b/hugo.yaml @@ -133,11 +133,6 @@ params: # current doc set. version: v1.17 - # Flag used in the "version-banner" partial to decide whether to display a - # banner on every page indicating that this is an archived version of the docs. - # Set this flag to "true" if you want to display the banner. - archived_version: false - # A link to latest version of the docs. Used in the "version-banner" partial to # point people to the main doc site. url_latest_version: https://docs.dapr.io From 101675e5c3b2ed8bfbe4a6df7df2e3bc4e96fad9 Mon Sep 17 00:00:00 2001 From: pittu sharma Date: Mon, 20 Apr 2026 23:10:36 +0530 Subject: [PATCH 3/3] docs: clarify continue-as-new behavior for child workflows #5021 Signed-off-by: pittu sharma --- .../workflow/workflow-features-concepts.md | 4 +++ .../workflow/workflow-patterns.md | 33 ++++++++++--------- 2 files changed, 22 insertions(+), 15 deletions(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-features-concepts.md b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-features-concepts.md index 6886a10313d..bd4a330cc7b 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-features-concepts.md +++ b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-features-concepts.md @@ -118,6 +118,10 @@ 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. + {{% alert title="Note" color="primary" %}} + _Continue-as-new_ proceeds immediately without waiting for child workflows that were started but not awaited. + {{% /alert %}} + > The _continue-as-new_ API truncates the existing history, replacing it with a new history. 1. **Use child workflows**: diff --git a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md index 8158ddfdbbc..f5784f46710 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md +++ b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md @@ -46,25 +46,25 @@ def task_chain_workflow(ctx: wf.DaprWorkflowContext, wf_input: int): def step1(ctx, activity_input): print(f'Step 1: Received input: {activity_input}.') - # Do some work + # Add step-specific logic here (e.g. data transformation) return activity_input + 1 def step2(ctx, activity_input): print(f'Step 2: Received input: {activity_input}.') - # Do some work + # Add step-specific logic here (e.g. data transformation) return activity_input * 2 def step3(ctx, activity_input): print(f'Step 3: Received input: {activity_input}.') - # Do some work + # Add step-specific logic here (e.g. data transformation) return activity_input ^ 2 def error_handler(ctx, error): print(f'Executing error handler: {error}.') - # Apply some compensating work + # Add logic here to undo partial changes (e.g., release inventory) ``` > **Note** Workflow retry policies will be available in a future version of the Python SDK. @@ -139,7 +139,7 @@ async function start() { start().catch((e) => { console.error(e); process.exit(1); - # Apply custom compensation logic + // Add logic here to undo partial changes (e.g., refund payment) }); ``` @@ -201,7 +201,7 @@ public class ChainWorkflow extends Workflow { public Object run(WorkflowActivityContext ctx) { Logger logger = LoggerFactory.getLogger(Step1.class); logger.info("Starting Activity: " + ctx.getName()); - // Do some work + // Add step-specific logic here (e.g. data transformation) return null; } } @@ -212,7 +212,7 @@ public class ChainWorkflow extends Workflow { public Object run(WorkflowActivityContext ctx) { Logger logger = LoggerFactory.getLogger(Step2.class); logger.info("Starting Activity: " + ctx.getName()); - // Do some work + // Add step-specific logic here (e.g. data transformation) return null; } } @@ -223,7 +223,7 @@ public class ChainWorkflow extends Workflow { public Object run(WorkflowActivityContext ctx) { Logger logger = LoggerFactory.getLogger(Step3.class); logger.info("Starting Activity: " + ctx.getName()); - // Do some work + // Add step-specific logic here (e.g. data transformation) return null; } } @@ -739,6 +739,11 @@ Depending on the business needs, there may be a single monitor or there may be m Dapr Workflow supports this pattern natively by allowing you to implement _eternal workflows_. Rather than writing infinite while-loops ([which is an anti-pattern]({{% ref "workflow-features-concepts.md#infinite-loops-and-eternal-workflows" %}})), Dapr Workflow exposes a _continue-as-new_ API that workflow authors can use to restart a workflow function from the beginning with a new input. +{{% alert title="Note" color="primary" %}} +_Continue-as-new_ proceeds immediately without waiting for child workflows that were started but not awaited. This allows the monitor pattern to continue its loop while child workflows are still running. +{{% /alert %}} + + {{< tabpane text=true >}} {{% tab "Python" %}} @@ -795,12 +800,10 @@ const statusMonitorWorkflow: TWorkflow = async function* (ctx: WorkflowContext): const status = yield ctx.callActivity(checkStatusActivity); if (status === "healthy") { // Check less frequently when in a healthy state - // set duration to 1 hour duration = 60 * 60; } else { yield ctx.callActivity(alertActivity, "job unhealthy"); // Check more frequently when in an unhealthy state - // set duration to 5 minutes duration = 5 * 60; } @@ -1099,7 +1102,7 @@ async function start() { // Orders of $1000 or more require manager approval yield ctx.callActivity(sendApprovalRequest, order); - // Approvals must be received within 24 hours or they will be cancled. + // Approvals must be received within 24 hours or they will be cancelled. const tasks: Task[] = []; const approvalEvent = ctx.waitForExternalEvent("approval_received"); const timeoutEvent = ctx.createTimer(24 * 60 * 60); @@ -1179,7 +1182,7 @@ start().catch((e) => { ```csharp public override async Task RunAsync(WorkflowContext context, OrderPayload order) { - // ...(other steps)... + // Initial business logic (e.g. inventory check) // Require orders over a certain threshold to be approved if (order.TotalCost > OrderApprovalThreshold) @@ -1206,7 +1209,7 @@ public override async Task RunAsync(WorkflowContext context, OrderP } } - // ...(other steps)... + // Final business logic (e.g. shipping confirmation) // End the workflow with a success result return new OrderResult(Processed: true); @@ -1224,7 +1227,7 @@ public class ExternalSystemInteractionWorkflow extends Workflow { @Override public WorkflowStub create() { return ctx -> { - // ...other steps... + // Initial business logic (e.g. inventory check) Integer orderCost = ctx.getInput(int.class); // Require orders over a certain threshold to be approved if (orderCost > ORDER_APPROVAL_THRESHOLD) { @@ -1242,7 +1245,7 @@ public class ExternalSystemInteractionWorkflow extends Workflow { ctx.complete("Process cancel"); } } - // ...other steps... + // Final business logic (e.g. shipping confirmation) // End the workflow with a success result ctx.complete("Process approved");