Remove undefined trace flags

[bogdandrutu]

The current spec does not define flags properties for: IsDeferred and IsDebug. See https://github.com/open-telemetry/opentelemetry-go/blob/main/trace/trace.go#L345

[MrAlias]

Thanks for opening this. These fields are used to satisfy this part of the specification:

When extracting B3, propagators:
...
MUST preserve a debug trace flag, if received, and propagate it with subsequent requests. Additionally, an OpenTelemetry implementation MUST set the sampled trace flag when the debug flag is set.

Did you have a suggestion for how we can propagate these if that is not used?

[bogdandrutu]

There are some options that I can think of:

1. Propagate them as a different entry in the Context, this is what Java does. I think this is safe, if debug then you set sampled and propagate the debug bool in the context, because only if the user uses extract and inject b3 it matters.
2. Just remove the API to retrieve them and treat everything else except the Sample bit as opaque (not sure if this causes any problem, but I would like to think about this). The problem that I need to understand is what happens if w3c/opentelemetry adds a different meaning for the second bit.

[MrAlias]

1. Propagate them as a different entry in the Context, this is what Java does.

The SpanContext struct is a concept of the SDK not the propagators. The propagator never sees the SpanContext but only deals with a context.Context. Setting a specific field in a context.Context that is returned from the extract field will mean that the SDK will then need to determine if that field is set and propagate it. This will couple the tracing SDK with a propagator extraction logic which does not seem appropriate.

2. Just remove the API to retrieve them and treat everything else except the Sample bit as opaque (not sure if this causes any problem, but I would like to think about this).

This would mean this implementation of the B3 propagation does not implement the specification. Propagating a sampling decision of 1 is not equivalent to d in the single header format. Additionally, the concept of defer is not equivalent to sampled and we would want to preserve this information for the sampler.

The problem that I need to understand is what happens if w3c/opentelemetry adds a different meaning for the second bit.

This is an interesting association. The W3C trace context flags field is not the same as the TraceFlags field in this project, nor does it need to be AFAIK. If OpenTelemetry adds additional trace flags it there is still space to store additional information in this type so I'm not sure we wouldn't be able to accommodate this addition.

[bogdandrutu]

This is an interesting association. The W3C trace context flags field is not the same as the TraceFlags field in this project, nor does it need to be AFAIK. If OpenTelemetry adds additional trace flags it there is still space to store additional information in this type so I'm not sure we wouldn't be able to accommodate this addition.

See the specification:
https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#spancontext

[MrAlias]

See the specification:
https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#spancontext

I'm not following. Can you quote the line that is relevant to your point?