Span baggage processor & no Baggage When Start

[AndresBena19]

Describe the bug
The BaggageSpanProcessor is currently listening on Start for every span and getting the baggage from the context, but as the SpanBuilderShim is not setting the baggage data that point when the SpanProcessor intercept the start, there is not baggage to attach

opentelemetry-java/opentracing-shim/src/main/java/io/opentelemetry/opentracingshim/SpanBuilderShim.java

Line 227 in 567e737

io.opentelemetry.api.trace.Span span = builder.startSpan();

https://github.com/open-telemetry/opentelemetry-java-contrib/blob/c2c62aa97383412663fbe198c4259e17ea26ac6b/baggage-processor/src/main/java/io/opentelemetry/contrib/baggage/processor/BaggageSpanProcessor.java#L40

I found while working with this temporal open tracing interceptors

https://github.com/temporalio/sdk-java/blob/c67ca608d88e78f942dfaa4a0f4280f95e35d012/temporal-opentracing/src/main/java/io/temporal/opentracing/internal/OpenTracingWorkflowClientCallsInterceptor.java#L30

Steps to reproduce
If possible, provide a recipe for reproducing the error.

What did you expect to see?
Expected to see the context extracting the baggage data from the parent context and propagate baggage to the span attributes

What did you see instead?
Baggage .fromContext no finding baggage data

What version and what artifacts are you using?
Artifacts: (e.g., opentelemetry-api, opentelemetry-sdk, which exporters, etc)
Version: (e.g., v0.4.0, 1eb551b, etc)
How did you reference these artifacts? (excerpt from your build.gradle, pom.xml, etc)

Environment
Compiler: (e.g., "Temurin 17.0.7")
OS: (e.g., "Ubuntu 20.04")
Runtime (if different from JDK above): (e.g., "Oracle JRE 8u251")
OS (if different from OS compiled on): (e.g., "Windows Server 2019")

Additional context
Add any other context about the problem here.

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[zeitlinger]

Would it be possible to adjust the order in the shim to make it work?

I haven't tried it out myself yet.

[AndresBena19]

I found this opentelemetry and opentracing compatibility doc

https://opentelemetry.io/docs/specs/otel/compatibility/opentracing/#span-shim-and-spancontext-shim-relationship

so basically as temporal is using the shim behind the scenes to transform opentracing traces to opentelemetry traces and the BaggageSpanProcessor is using a SpanProcessor (from the otel API) then it is not possible to fetch the baggage data at that point.

Any temporal workaround for this?

[zeitlinger]

I guess you'd need to hard code the baggage span processor into the shim.

I'm not sure if this would be accepted into this repo - mainly because the shim is already very old.

@jkwatson @jack-berg wdyt?

[jkwatson]

I don't understand what that spec reference is trying to say, TBH. Are we missing a part of the shim implementation that we should have?

[AndresBena19]

@jkwatson

Problem Statement:

We're using Temporal with OpenTelemetry instrumentation in our project. Temporal uses an OpenTracing + OpenTelemetry shim for compatibility. In our services, we use OpenTelemetry's SpanProcessor to intercept span creation and modify spans before export. Specifically, we extract baggage data and attach certain baggage values as span attributes.

The Issue:

When the OpenTracing shim creates and starts a span (via builder.startSpan()), our SpanProcessor is triggered as expected. However, at this point in the span lifecycle in opentracing, the baggage context is not yet available, so we cannot access the baggage values we need to attach as span attributes.

So after read a bit more the open-telemetry docs i found this, https://opentelemetry.io/docs/specs/otel/compatibility/opentracing/#span-shim-and-spancontext-shim-relationship, which is kind of explaining the limitation when using opentracing + opentelemetry in the same system and specifically when opentelemetry API components (SpanProcessors) want to access things like baggage.

[jkwatson]

Yes, I read all of that before. I don't know what you're proposing as a solution, though, and the spec reference doesn't seem to clarify anything for me. Is our Java implementation lacking, or is this a fundamental issue with OTel+OT that needs to be sorted out at the spec level?

[AndresBena19]

@jkwatson yes, seems like is a fundamental issue with OTel + OT, I will propose temporal to support open telemetry natively for the java sdk instead of the open tracing + shim, so that we do not have to add workarounds for all the documented compatibility issues when using OT and OTel in the same project