B3 propagation does not handle ParentSpanId

[toumorokoshi]

Currently the b3 propagator does not handle the ParentSpanId. this is a field that does not exist in w3c tracecontext:

https://github.com/openzipkin/b3-propagation#parentspanid

I believe to do this properly, we need to:

1. generate a single string version of the headers and add it into tracestate under the "b3" key.
2. inject the values by extracting them from the tracestate.

Thoughts?

[ocelotl]

Would it make sense to have something like B3SpanContext, who would inherit from SpanContext and would have an additional attribute named parentspanid? The same approach could be applied to support future implementations of propagators.

[toumorokoshi]

@ocelotl what's the motivation for that vs including it in the tracestate? I believe the purpose of tracestate is specifically to support vendor or other implementations:

https://www.w3.org/TR/trace-context/#tracestate-header

The con I see for extending the class is multiple different SpanContext implementations that expose different fields. Then whatever exporter or system that consumes that data would have to be aware of the existing of that field.

But I'd love to hear someone more involve in tracecontext's perspective. Maybe @reyang?

[ocelotl]

@toumorokoshi Oh, there is no specific motivation, I'm just understanding this 😅

Ok, so you suggest something like this?

span_context = some_b3_format_object.extract(...)
span_context.tracestate == {
    "x-b3-parentid": "someparentid"
}

Maybe is better to use a more specific key in tracestate (like x-b3-parentid, instead of just b3) in case the B3 specification adds another field later and we would want to follow the same approach for it.

[ocelotl]

... or maybe x-b3-parentid@b3 would be a even better key?

[toumorokoshi]

I'd probably suggest just writing out a single key for b3 in general, so maybe just call it "b3"?

Maybe worth talking to opentelemetry-js folks. A quick scan and I think only they've implemented b3 header propagation: https://github.com/open-telemetry/opentelemetry-js/blob/19756471a629a6b9f083ab8c3c5c95495c3fbffb/packages/opentelemetry-core/src/context/propagation/B3Format.ts

I don't think it's necessarily explicit, but it is implied a single vendor should use a single key here: https://www.w3.org/TR/trace-context/#combined-header-value

[toumorokoshi]

to be clear: I was suggesting calling it "b3" and then encoding the parent-id. But I think as this is just an implementation detail under the hood and clashes are rare, you could probably just call it x-b3-parentid or b3-parentid.

I don't see a lot in the tracecontext spec as how to actually encode values. I might suggest grabbing someone on the community gitter to voice their opinion.

[Oberon00]

Would this be solved if the injector got a Span instead of a SpanContext as input?

[ocelotl]

@Oberon00 thanks for the suggestion, but how would that solve the issue? If I understand this correctly, we would still need to use the span's context in inject to get the necessary attributes. Please correct me if I am not understanding this right.

I added an implementation in #286, it is just my attempt to code the original idea of @toumorokoshi 😄

[Oberon00]

Your PR handles extraction only. The more interesting problem is injection IMHO. But tbh, from the "spec" at https://github.com/openzipkin/b3-propagation#parentspanid I don't really get what the parent span ID is supposed to be.

Ah, upon reading https://github.com/openzipkin/b3-propagation#why-is-parentspanid-propagated, it seems that actually we currently handle the b3-span-id wrong: Span ID is supposed to become the ID of the child span, if I'm reading this correctly.

[Oberon00]

From reading this, it seems that the OpenTelemetry trace propagation model is incompatible with the B3 model.