Understanding the pitfalls of Activity.AddBaggage

[danelson]

The Baggage API contains the following disclaimer.

The recommended way to add Baggage is to use the Baggage.SetBaggage() API. OpenTelemetry users should not use the Activity.AddBaggage method.

What it the rationale for this?

I have a legacy application that supports a plugin model. Unfortunately bootstrapping and client code runs in the same app domain. This results in potential dll versioning conflicts. I was hoping to suggest plugins only take a dependency on a specific version System.Diagnostics.DiagnosticSource but that breaks the guidance above.

If I ignore the guidance, what type of pitfalls might I encounter?

[cijothomas]

OTel propagators does not understand Baggage added via Activity.AddBaggage. Activity has baggage concept even before Otel, and it was tied to Activity. However OTel baggage is not tied to tracing, and is applicable to every signals (logs, metrics), and should work irrespective of whether tracing is enabled or not

[danelson]

In this use case I have an ActivityListener that maps baggage to span attributes. It is purely for use within a given process so no propagation is needed. I believe that it is therefore safe to use in my scenario.

Thank you for the clarity.