Make workflow activity trace ids available to application code
In what area(s)?
/area runtime
Describe the feature
Currently, whenever a workflow activity is invoked, it does not receive the id of the parent span that dapr creates.
This prevents a great opportunity for users to get increased visibility and correlation between dapr and their application code.
Using the csharp workflow fundamentals quickstart as an example, you can imagine what the code might be able to look like after this is made possible and corresponding SDKs are updated:
using System.Diagnostics;
using Dapr.Workflow;
namespace Basic.Activities;
internal sealed class Activity1(ActivitySource activitySource) : WorkflowActivity<string, string>
{
public override Task<string> RunAsync(WorkflowActivityContext context, string input)
{
// This is the part that doesn't exist today and that it would be great to have dapr facilitate...
var parentSpanId = context.ParentSpanId;
// ...and then with the `parentSpanId` in hand, we can initialize a `System.Diagnostics` trace.
using var myActivitySpan = activitySource.StartActivity(nameof(Activity1),ActivityKind.Internal, parentSpanId)
?? throw new("Unable to start activity!");
Console.WriteLine($"{nameof(Activity1)}: Received input: {input}.");
return Task.FromResult($"{input} Two" );
}
}
+1 to this.
FWIW, docs do state it's currently not possible: https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-architecture/
Workflow activity code currently does not have access to the trace context.
@JoshVanL This PR suggests that this feature might be coming... ?
https://github.com/dapr/durabletask-go/pull/39/files#diff-c4f4f51dd4b6309e761681af240f6216400c0bac8265a89bb62b22817f525eed
@JoshVanL This PR suggests that this feature might be coming... ?
https://github.com/dapr/durabletask-go/pull/39/files#diff-c4f4f51dd4b6309e761681af240f6216400c0bac8265a89bb62b22817f525eed
The watch of a hawk :D Yes, that's the plan.
Related? #8947