feat: propagate caller trace context when scheduling workflows#1783
Open
javier-aliaga wants to merge 2 commits into
Open
feat: propagate caller trace context when scheduling workflows#1783javier-aliaga wants to merge 2 commits into
javier-aliaga wants to merge 2 commits into
Conversation
Upstream half of workflow trace propagation (follow-up to dapr#1619). DaprWorkflowClient gains a DaprWorkflowClient(Properties, Tracer) constructor that passes the tracer to the internal DurableTaskGrpcClientBuilder. DurableTaskGrpcClient now uses the configured tracer when scheduling: it emits a create_orchestration CLIENT span as a child of the caller's current OpenTelemetry context and stamps its W3C trace context into CreateInstanceRequest.parentTraceContext, so the workflow execution nests under the caller's trace instead of starting a separate one. Tracing stays opt-in: without a tracer the request is unchanged and no spans are emitted. The unused GlobalOpenTelemetry fallback is removed so the global instance is never pulled implicitly. Signed-off-by: Javier Aliaga <javier@diagrid.io>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adds opt-in OpenTelemetry trace propagation when scheduling workflows so that workflow executions can be nested under the caller’s active trace context (instead of starting a separate trace), while preserving legacy behavior when no tracer is configured.
Changes:
- Add a new
DaprWorkflowClient(Properties, Tracer)constructor and pass the tracer into the underlyingDurableTaskGrpcClientBuilder. - Update
DurableTaskGrpcClientscheduling to emit acreate_orchestrationCLIENT span and populateCreateInstanceRequest.parentTraceContextwith W3C trace context (when a tracer is configured). - Add tests covering tracer propagation behavior (including no-op tracer) and update module dependencies accordingly.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| sdk-workflows/src/test/java/io/dapr/workflows/client/DaprWorkflowClientTest.java | Adds unit tests verifying tracer forwarding to DurableTaskGrpcClientBuilder and null-tracer behavior. |
| sdk-workflows/src/main/java/io/dapr/workflows/client/DaprWorkflowClient.java | Introduces Properties, Tracer constructor and threads tracer into durable task client construction. |
| sdk-workflows/pom.xml | Adds opentelemetry-api dependency needed for the public Tracer type. |
| durabletask-client/src/test/java/io/dapr/durabletask/DurableTaskGrpcClientTracingTest.java | Adds in-process gRPC test validating parentTraceContext propagation and no-op tracer behavior. |
| durabletask-client/src/main/java/io/dapr/durabletask/DurableTaskGrpcClient.java | Implements span creation + W3C trace context injection into scheduling request; removes implicit GlobalOpenTelemetry fallback. |
| durabletask-client/pom.xml | Adds opentelemetry-sdk test dependency to support tracer provider usage in tests. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…eptions Addresses review feedback: the create_orchestration span is now current while the sidecar call runs, so nested instrumentation attaches to it, and failures record the exception on the span in addition to the error status. Signed-off-by: Javier Aliaga <javier@diagrid.io>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1783 +/- ##
============================================
+ Coverage 76.89% 76.90% +0.01%
- Complexity 2307 2309 +2
============================================
Files 244 244
Lines 7163 7167 +4
Branches 753 754 +1
============================================
+ Hits 5508 5512 +4
Misses 1288 1288
Partials 367 367 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
salaboy
reviewed
Jul 7, 2026
| if (this.tracer != null) { | ||
| span = this.tracer.spanBuilder("create_orchestration:" + orchestratorName) | ||
| .setSpanKind(SpanKind.CLIENT) | ||
| .setAttribute("durabletask.type", "orchestration") |
Collaborator
There was a problem hiding this comment.
@javier-aliaga this is confusing already.. why DurableTask here? can you not make it "workflow."
Contributor
Author
There was a problem hiding this comment.
we still have durabletask.* all around the place
salaboy
reviewed
Jul 7, 2026
salaboy
reviewed
Jul 7, 2026
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.
Upstream half of workflow trace propagation (follow-up to #1619).
DaprWorkflowClient gains a DaprWorkflowClient(Properties, Tracer) constructor that passes the tracer to the internal DurableTaskGrpcClientBuilder. DurableTaskGrpcClient now uses the configured tracer when scheduling: it emits a create_orchestration CLIENT span as a child of the caller's current OpenTelemetry context and stamps its W3C trace context into
CreateInstanceRequest.parentTraceContext, so the workflow execution nests under the caller's trace instead of starting a separate one.
Tracing stays opt-in: without a tracer the request is unchanged and no spans are emitted. The unused GlobalOpenTelemetry fallback is removed so the global instance is never pulled implicitly.
Description
Please explain the changes you've made
Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Please reference the issue this PR will close: #[issue number]
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list: