Consider bi-directional context-scoped attribute propagation

[dyladan]

The OTEP (#4931) and the Java prototype propagate context-scoped attributes forward only. Attributes set in context are picked up by child spans at start time. This issue proposes discussing whether attributes should also be propagated to ancestor spans, redefining the idea of "context" as the whole branch of the trace, not just the part of the branch below the current context.

Motivation

A common need when generating span-derived metrics (request duration, request count, error rate) is to split those metrics by dimensions that are not known when the entrypoint span starts. For example:

• Was a particular third-party service called?
• Was a database accessed during this request?
• Was a specific feature flag active?

This information becomes available in child spans or instrumentations that run mid-request, but the dimension needs to live on the root/entrypoint span (typically an HTTP server span) to be useful in metrics.

Alternatives Considered

• Hold a reference to the entrypoint span and set attributes from child instrumentations. This couples instrumentations to each other and doesn't work with OOTB instrumentations that don't expose a hook for this.
• SpanProcessor that copies child attributes to ancestors. The spec provides no way to get a span's parent (only the parent SpanContext), so the processor has to hold references to all open entrypoint spans itself. Processors also only run on span start/end, so attributes set mid-span may be missed if the root span closes before the child that triggered the attribute. It is also challenging in some languages to implement without leaking memory due to the lack of weak references
• Monkeypatching the SDK. Obvious downsides.

Related use cases

Others have raised related cases that also require some form of back-propagation:

• Counting the number of child spans under a given span
• Tenant ID and app ID (mentioned in the OTEP) may not be known at the head of the trace
• Collector span-to-metrics pipelines, which are largely stateless, would benefit from attributes being available at the root span level

_{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.}

[MrAlias]

Heads up on this, Go context follows the DAG model of tracing (each edge has an orientation). The context has no concept of its heredity and cannot be changed to accommodate that given it is a built-in to the language. A solution relying on this functionality in the context will not be possible in Go.