[API Proposal]: System.Diagnostics.ActivityContext.Current ability or similar

[cretz]

Background and motivation

People need to be able to set the (async local) current activity context for parenting without being forced to create/start an activity. In OTel this is referred to as "attach context".

In my particular use case, I re-obtain activity context and baggage via OTel propagation in a general library, and I need to set that context as the "current" context for implicit parenting by all basic uses of ActivitySource.CreateActivity and ActivitySource.StartActivity downstream. I cannot afford to create an activity every time just to get the parent context on the implicit async local nor is it reasonable for me to ask all users of the application to use create/start overload and manually access my custom ActivityContext.Current async local for every activity created.

An ActivityContext.Current would be defaulted in the internal ActivitySource.CreateActivity if it's present after choosing the context on the current activity. That way existing behavior remains the same as today. So what was effectively var context = contextParam ?? Activity.Current?.Context would become var context = contextParam ?? Activity.Current?.Context ?? ActivityContext.Current.

API Proposal

public readonly struct ActivityContext
{
    // ...

    public static ActivityContext? Current { get; set; }
}

It is up for discussion whether ActivityContext.Current getter should return the Activity.Current?.Context if there is not an explicit async local one.

API Usage

public void MyThing()
{
    var existingActivity = Activity.Current;
    var existingContext = ActivityContext.Current;
    Activity.Current = null;
    ActivityContext.Current = DeserializeFromPropagatedCarrier();
    try
    {
        RunDownstreamCode();
    }
    finally
    {
        Activity.Current = existingActivity;
        ActivityContext.Current = existingContext;
    }
}

With that, I have effectively performed attach context without starting a new activity.

Alternative Designs

An alternative approach would be to support creating an activity from a context, but that may be more confusing/problematic because people expect activities to be created where they start and not be able to be rehydrated from a context.

Risks

Primary risk is user confusion of knowing which implicit context is used for parenting by default at create/start activity call.

Tagging subscribers to this area: @dotnet/area-system-diagnostics-activity
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

People need to be able to set the (async local) current activity context for parenting without being forced to create/start an activity. In OTel this is referred to as "attach context".

In my particular use case, I re-obtain activity context and baggage via OTel propagation in a general library, and I need to set that context as the "current" context for implicit parenting by all basic uses of ActivitySource.CreateActivity and ActivitySource.StartActivity downstream. I cannot afford to create an activity every time just to get the parent context on the implicit async local nor is it reasonable for me to ask all users of the application to use create/start overload and manually access my custom ActivityContext.Current async local for every activity created.

An ActivityContext.Current would be defaulted in the internal ActivitySource.CreateActivity if it's present after choosing the context on the current activity. That way existing behavior remains the same as today. So what was effectively var context = contextParam ?? Activity.Current?.Context would become var context = contextParam ?? Activity.Current?.Context ?? ActivityContext.Current.

API Proposal

public readonly struct ActivityContext
{
    // ...

    public static ActivityContext? Current { get; set; }
}

It is up for discussion whether ActivityContext.Current getter should return the Activity.Current?.Context if there is not an explicit async local one.

API Usage

public void MyThing()
{
    var existingActivity = Activity.Current;
    var existingContext = ActivityContext.Current;
    Activity.Current = null;
    ActivityContext.Current = DeserializeFromPropagatedCarrier();
    try
    {
        RunDownstreamCode();
    }
    finally
    {
        Activity.Current = existingActivity;
        ActivityContext.Current = existingContext;
    }
}

With that, I have effectively performed attach context without starting a new activity.

Alternative Designs

An alternative approach would be to support creating an activity from a context, but that may be more confusing/problematic because people expect activities to be created where they start and not be able to be rehydrated from a context.

Risks

Primary risk is user confusion of knowing which implicit context is used for parenting by default at create/start activity call.

Author:	cretz
Assignees:	-
Labels:	api-suggestion, area-System.Diagnostics.Activity
Milestone:	-

[tarekgh]

@cijothomas @reyang @CodeBlanch Isn't this already supported by OTel context propagators?

CC @noahfalk

[cretz]

OTel context propagation only supports serializing/deserializing to OpenTelemetry.Context.Propagation.PropagationContext which is just an ActivityContext + Baggage combo. But the example that https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry.Api/README.md#context-propagation points to for inject and extract require you to start an activity to use the propagated context because .NET has no facility to set a context without an activity being created.

[tarekgh]

But the example that open-telemetry/opentelemetry-dotnet@main/src/OpenTelemetry.Api/README.md#context-propagation points to for inject and extract require you to start an activity to use the propagated context because .NET has no facility to set a context without an activity being created.

I am not sure this is true. you can create your own context and inject it without creating any Activity objects. The snippet in the code is just using Activity for demonstration. but you can create your own context using new ActivityContext and inject it.

                ActivityContext contextToInject = default;
                if (activity != null)
                {
                    contextToInject = activity.Context;
                }
                else if (Activity.Current != null)
                {
                    contextToInject = Activity.Current.Context;
                }

                // Inject the ActivityContext into the message headers to propagate trace context to the receiving service.
                Propagator.Inject(new PropagationContext(contextToInject, Baggage.Current), props, this.InjectTraceContextIntoBasicProperties);

[cretz]

It is true when you need to use the propagated context implicitly. You cannot have all downstream activities use an implicit context for parenting, .NET requires they only use implicit activities for parenting.

My use case is to let users create their own activities via normal StartActivity/CreateActivity. As an exercise, take this user code:

public void DoThing()
{
    using (myActivitySource.StartActivity("foo"))
    {
        DoSomethingElse();
    }
}

We need to implement RunThingWithContextPropagated in our library such that they can call RunThingWithContextPropagated(() => DoThing()). But we don't want to create an activity for our call because it'd be far too noisy. It is a normal operation to restore a context to its implicit place without creating a span in OTel.

So how do we write RunThingWithContextPropagated?

public void RunThingWithContextPropagated(Action action)
{
    var ctx = ExtractViaPropagationContextSomehow();

    // TODO: What do I do here to make the downstream `StartActivity` _implicitly_ use that context?
    // We DO NOT want to create a new activity everytime this function is called.
    
    action();
}

I hope that helps clarify. This is a very normal thing in OTel (and OpenTracing and most other tracing approaches) to be able to rehydrate a span/activity context that becomes the implicit parent without being forced to create a span. I can show how this is done in other OTel impls (e.g. https://opentelemetry-python.readthedocs.io/en/latest/api/context.html#opentelemetry.context.attach).