workflow history propagation docs#5153
Open
cicoyle wants to merge 8 commits into
Open
Conversation
Signed-off-by: Cassandra Coyle <cassie@diagrid.io>
Contributor
There was a problem hiding this comment.
Pull request overview
Adds documentation for “workflow history propagation” and links it from existing workflow docs to explain how a parent workflow can optionally share execution history with child workflows/activities.
Changes:
- Adds a new page describing workflow history propagation concepts, scopes, usage, and security considerations.
- Links the new page from the workflow overview and features/concepts pages.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md | Adds a new “History propagation” section linking to the new doc page. |
| daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-history-propagation.md | New doc page covering propagation scopes, setup, consuming history, and cross-app/security notes. |
| daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-features-concepts.md | Adds a short “Workflow history propagation” section and links to the detailed page. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
cicoyle
changed the title
Signed-off-by: Cassandra Coyle <cassie@diagrid.io>
Signed-off-by: Cassandra Coyle <cassie@diagrid.io>
Contributor
nelson-parente
left a comment
nelson-parente
left a comment
There was a problem hiding this comment.
Pre-review for @marcduiker handoff: LGTM. New conceptual page for workflow history propagation (164 lines) with accurate Go code examples using the durabletask-go SDK API (WithHistoryPropagation, PropagateLineage, PropagateOwnHistory, GetPropagatedHistory). Scope comparison table is clear. Pointers from workflow-overview.md and workflow-features-concepts.md are in place. Note: this covers the Go SDK; the .NET SDK doc is in #5174 — coordinate to make sure both land together or are independently valid. Safe to merge after CI.
Signed-off-by: Cassandra Coyle <cassie@diagrid.io>
msfussell
reviewed
May 27, 2026
| - **Lineage** — caller's events plus the full ancestor chain (chain-of-custody) | ||
| - **Own history** — caller's events only (a trust boundary, ancestral lineage dropped) | ||
|
|
||
| The receiving workflow/activity reads its inherited history via `ctx.GetPropagatedHistory()` and can verify what happened upstream — useful for fraud checks, compliance gates, and long-running AI agents that need context across hops. |
Member
There was a problem hiding this comment.
Suggested change
| The receiving workflow/activity reads its inherited history via `ctx.GetPropagatedHistory()` and can verify what happened upstream — useful for fraud checks, compliance gates, and long-running AI agents that need context across hops. | |
| The receiving workflow/activity reads its inherited history via the SDKs `GetPropagatedHistory()` API and can verify what happened upstream. |
make this SDK agnostic, since all the SDK will have this API name (not just Go)
|
|
||
| ## Workflow history propagation | ||
|
|
||
| A parent workflow can opt to share its execution history with downstream child workflows and activities. Two scopes are available: |
Member
There was a problem hiding this comment.
I would include a scenario description in the feature section, so that people understand when this can be used with some suggestions, examples. Something like this.
Suggested change
| A parent workflow can opt to share its execution history with downstream child workflows and activities. Two scopes are available: | |
| Workflow history propagation enables a current workflow to look back over the set of events that the workflow or a another workflow has executed and verify these actually occurred. Some scenarios include performance fraud checks, checking compliance gates, or enable long-running AI agents/workflows to maintain context across calls (multi-agent, multi-app workflows) to determine what the agent or workflows claims to have done, it actually true. | |
| For example if you have a workflow that verifies a credit check for a user, you can use workflow history propagation to verify this actually happened for the named user. When this is combined with workflow history signing, you can further cryptographically confirm or attest this. | |
| A parent workflow can opt to share its execution history with downstream child workflows and activities. Two scopes are available: |
|
|
||
| The receiving workflow/activity reads its inherited history via `ctx.GetPropagatedHistory()` and can verify what happened upstream — useful for fraud checks, compliance gates, and long-running AI agents that need context across hops. | ||
|
|
||
| For details, the scope comparison, and code examples, see [History propagation]({{< ref workflow-history-propagation.md >}}). |
Member
There was a problem hiding this comment.
Suggested change
| For details, the scope comparison, and code examples, see [History propagation]({{< ref workflow-history-propagation.md >}}). | |
| For details, the scope comparison, and code examples, see [workflow history propagation]({{< ref workflow-history-propagation.md >}}). |
| description: "Share a parent workflow's execution history with child workflows and activities for chain-of-custody, audit, and AI-agent context" | ||
| --- | ||
|
|
||
| By default, a child workflow or activity only sees the input it was scheduled with. The parent's execution history — what activities ran, what child workflows it spawned, what events it observed — is invisible. Workflow history propagation lets a parent opt-in to share that history with the work it schedules. |
Member
There was a problem hiding this comment.
I would add a some scenarios into this article as well, in case most likely, that some comes straight to this article from a search (like I suggest in the overview)
| description: "Share a parent workflow's execution history with child workflows and activities for chain-of-custody, audit, and AI-agent context" | ||
| --- | ||
|
|
||
| By default, a child workflow or activity only sees the input it was scheduled with. The parent's execution history — what activities ran, what child workflows it spawned, what events it observed — is invisible. Workflow history propagation lets a parent opt-in to share that history with the work it schedules. |
Member
There was a problem hiding this comment.
I would add a some scenarios into this article as well, in case most likely, that some comes straight to this article from a search (like I suggest in the overview)
|
|
||
| ## ContinueAsNew and rerun | ||
|
|
||
| Propagated history flows correctly through both `ContinueAsNew` and rerun: |
Member
There was a problem hiding this comment.
Suggested change
| Propagated history flows correctly through both `ContinueAsNew` and rerun: | |
| Propagated history is correctly maintained with both `ContinueAsNew` and `Rerun` workflow operations. |
|
|
||
| Propagated history flows correctly through both `ContinueAsNew` and rerun: | ||
|
|
||
| - A workflow that received propagated history and calls `ContinueAsNew` passes the same incoming chunks to its next generation. |
Member
There was a problem hiding this comment.
Suggested change
| - A workflow that received propagated history and calls `ContinueAsNew` passes the same incoming chunks to its next generation. | |
| - A workflow that received propagated history and calls `ContinueAsNew` passes the same incoming context to its next generation. |
| Propagated history flows correctly through both `ContinueAsNew` and rerun: | ||
|
|
||
| - A workflow that received propagated history and calls `ContinueAsNew` passes the same incoming chunks to its next generation. | ||
| - Rerunning a workflow re-issues activity / child-workflow calls with the same propagation scope they were originally scheduled with — `LINEAGE` stays `LINEAGE`, `OWN_HISTORY` stays `OWN_HISTORY`. |
Member
There was a problem hiding this comment.
Suggested change
| - Rerunning a workflow re-issues activity / child-workflow calls with the same propagation scope they were originally scheduled with — `LINEAGE` stays `LINEAGE`, `OWN_HISTORY` stays `OWN_HISTORY`. | |
| - Re-running a workflow re-issues activity / child-workflow calls with the same propagation scope they were originally scheduled with — `LINEAGE` stays `LINEAGE`, `OWN_HISTORY` stays `OWN_HISTORY`. |
| This makes long-running agents and crash-recovery scenarios behave the way you'd expect: the receiving generation/rerun sees the same history the original run did. | ||
|
|
||
| ## Next steps | ||
|
|
Member
There was a problem hiding this comment.
Discover [how to apply workflow signing]({{% ref "workflow-history-signing.md" %}} to attest the validity of a previous workflow or activity step.
|
|
||
| ### History propagation | ||
|
|
||
| A parent workflow can opt to share its execution history with child workflows and activities — useful for chain-of-custody verification, fraud detection, audit, and AI-agent context that must flow across hops. |
Member
There was a problem hiding this comment.
Suggested change
| A parent workflow can opt to share its execution history with child workflows and activities — useful for chain-of-custody verification, fraud detection, audit, and AI-agent context that must flow across hops. | |
| Workflow history propagation enables a current workflow to look back over the set of events that the workflow or a another workflow has executed and verify these actually occurred. Scenarios include fraud checks, checking compliance gates (was this activity called or not), or enabling long-running AI agents/workflows to maintain context across calls (multi-agent, multi-app workflows) to determine what the agent or workflows claims to have done, it actually true. | |
| A parent workflow can opt to share its execution history with child workflows and activities — useful for chain-of-custody verification, fraud detection, audit, and AI-agent context that must flow across hops. | |
| For details, read [workflow history propagation ]({{% ref "workflow-history-propagation.md" %}} to understand how to apply this to a workflow, child workflow and activities. | |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
workflow history propagation docs