Support W3C Baggage propagation without Activity

[lmolkova]

Related to #45496

W3C Baggage defines a propagation format for arbitrary application-specific properties.
Despite being driven by the observability community, it's not related to W3C Trace-Context and could work without distributed tracing.

In .NET however, baggage API is part of the System.Diagnostics.Activity which allows to get/set baggage. It implies that users have to have distributed tracing enabled in order to propagate baggage.

To support W3C Baggage fully, .NET would need to define an API similar to OTel Baggage:

• NewBaggage.Current would be backed up by AsyncLocal
• NewBaggage would allow to add/get/remove/enumerate baggage

It could be done in a backward compatible way such that Activity.Baggage would work over NewBaggage, but it would be great to consider an alternative approach of sunsetting Activity.Baggage or at least methods allowing to add/modify it.

[dotnet-policy-service]

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

[julealgon]

In .NET however, baggage API is part of the System.Diagnostics.Activity which allows to get/set baggage. It implies that users have to have distributed tracing enabled in order to propagate baggage.

Where is that implication coming from? Isn't the entire System.Diagnostics set of types created in a way that is 100% agnostic? Activity itself has been in the framework for years and years before OTEL was even introduced.

[lmolkova]

In order to add/get/propagate a baggage, someone needs to create an Activity first. Activity is a distributed tracing primitive when used by OTel or without OTel.

There is nothing otel-specific in this issue description, so I'm not sure I understand your concern @julealgon.

[julealgon]

@lmolkova could you elaborate a bit on why this is needed and to which use cases it would apply?

[lmolkova]

service-a:

NewBaggage.Current.Add("foo", "bar");
DistributeContextPropagator.Current.InjectBaggage(NewBaggage.Current, httpRequest, ...);

service-b

var baggage = DistributeContextPropagator.Current.ExtractBaggage(NewBaggage.Current, httpRequest, ...);
NewBaggage.Current = new NewBaggage(baggage)

var foo = NewBaggage.Current.Get("foo");
...
// do anything with it.

Someone can use baggage to augment their telemetry (e.g. metrics or logs), to route requests in their application, or do absolutely anything with it.

[julealgon]

Thanks for the example @lmolkova , that helps.

All that static .Current provider pattern mess looks awful to me though... I wish we could achieve the same with properly injected services instead.

[tarekgh]

CC @noahfalk @samsp-msft

[cijothomas]

All that static .Current provider pattern mess looks awful to me though... I wish we could achieve the same with properly injected services instead.

Not sure what is the alternative here? .Current is static, but backed by asynclocal....

[julealgon]

All that static .Current provider pattern mess looks awful to me though... I wish we could achieve the same with properly injected services instead.

Not sure what is the alternative here? .Current is static, but backed by asynclocal....

To be fair I don't know either, was just a bit disappointed by the fact it's just a random static thing decoupled from everything else.

Wouldn't it make sense to somehow couple this with the Assembly or the Process, instead of them being "orphaned" classes/properties? What about the IHostEnvironment abstraction from Microsoft.Extension.Hosting, wouldn't that be a good fit?

My sentiment when seeing all this static provider-based stuff is that I'm working on a lower-level language.

[cijothomas]

static provider-based stuff

I am not sure if I understood the question well. What is "provider" here? Sure, OpenTelemetry has notion of various providers, but DiagnosticSource has no such concept of "providers".

[julealgon]

static provider-based stuff

I am not sure if I understood the question well. What is "provider" here? Sure, OpenTelemetry has notion of various providers, but DiagnosticSource has no such concept of "providers".

What I meant by "provider" is the pattern that allows you to assign and retrieve an implementation in a static fashion, which is usually modelled with this .Current method.

I was basically referring to this old system:

• https://www.codeproject.com/Articles/18222/Provider-Pattern

Provider pattern is one of the most interesting features that Microsoft introduced in .NET 2.
A lot of features including membership providers, roles providers, profile providers, health monitor event providers, site map providers, and more had the same design concept. These features are not changeable but extendable, and that is the beauty of the provider pattern.

When DI became "a thing", this "style" was largely abandoned, but there are still a few usages of the pattern in modern code.

I'd personally rather see something around the hosting abstractions than this.