Flask routes cannot be tagged as context propagation boundaries

[lizthegrey]

Is your feature request related to a problem?
We run the OTel demo app inside Glitch, which sends its own propagation headers for its own instrumentation. We explicitly want to distrust requests that come from Glitch rather than being sent trusted app to trusted app.

This issue would apply to anyone that doesn't sanitize their headers at the loadbalancer to remove context headers to their public endpoints.

Describe the solution you'd like
https://github.com/open-telemetry/opentelemetry-go/blob/master/plugin/othttp/handler.go#L73

[Oberon00]

What do you mean by "context propagation boundaries"? How would OpenTelemetry be able to help you in "distrusting"? I can only speculate that you are talking about the IsRemote property of the SpanContext, but please clarify this issue.

[lizthegrey]

If I get an HTTP request from somewhere I distrust, I shouldn't carry around its baggage or set its span id to my parent when instrumenting my handler, because I am my own service that shouldn't accept arbitrary client data.

the issue isn't isRemote or not, you can have trusted isRemote callers where context prop is appropriate, but there are also situations where context prop is not appropriate. you're right that isRemote=false usually means "trust this caller".

[Oberon00]

Wasn't the idea behind the W3C tracecontext that you could trace through systems that don't know anything of each other? Maybe related: open-telemetry/opentelemetry-specification#366

[lizthegrey]

"local root span" sounds right, yeah. I'm good with that approach.

[Oberon00]

I'm still not sure what the approach would be here / what the actual feature request is. Would implementing a "is local root" property solve your use case?

[lizthegrey]

Avoid having Jaeger and Honeycomb & pretty much every other analysis tool say "hey, you're missing the root span" // "hey, I'm missing a parent span of a span you've sent me"

[Oberon00]

Ah, I see. Personally I think this is a design problem of the W3C traceparent header, because the parent span ID part is mostly useless if you actually use the W3C header for its intended purpose to trace across different vendors. We might want to add a support for propagating the span ID as a custom key in the tracestate, see open-telemetry/opentelemetry-specification#366 (comment)

[lzchen]

Closing this for now. Will reopen if there's development in the specs.