Current context is empty with baggage.get_all

[process0]

Describe your environment

• Python 3.9.2
• opentelemetry-api == 1.9.1

Steps to reproduce

from opentelemetry import baggage, trace

tracer = trace.get_tracer(__name__)

global_ctx = baggage.set_baggage("context", "global")
with tracer.start_as_current_span(name="root span") as root_span:
    parent_ctx = baggage.set_baggage("context", "parent")
    with tracer.start_as_current_span(
        name="child span", context=parent_ctx
    ) as child_span:
        child_ctx = baggage.set_baggage("context", "child")
        print(baggage.get_all())
    print(baggage.get_all())
print(baggage.get_all())

print(baggage.get_all(global_ctx))
print(baggage.get_all(parent_ctx))
print(baggage.get_all(child_ctx))

What is the expected behavior?

{'context': 'child'}
{'context': 'parent'}
{'context': 'global'}
{'context': 'global'}
{'context': 'parent'}
{'context': 'child'}

What is the actual behavior?

{}
{}
{}
{'context': 'global'}
{'context': 'parent'}
{'context': 'child'}

Additional context
Add any other context about the problem here.

[Knifa]

Issue necromancy but wondering about this myself. What's the intention behind baggage context propagation (while trying not to overload this term) through spans?

with tracer.start_as_current_span(name="root span"):
    new_ctx = baggage.set_baggage("a", "b", context=context.get_current())
    new_ctx = baggage.set_baggage("c", "d", context=new_ctx)
    new_ctx = baggage.set_baggage("e", "f", context=new_ctx)

    with tracer.start_as_current_span(name="child span", context=new_ctx):
        print(baggage.get_all())

# >>> {}

I think this is further compounded because passing the created context=ctx to start_as_current_span doesn't actually attach to the context --- it's just used to grab the parent span.

with tracer.start_as_current_span(name="root span"):
    new_ctx = baggage.set_baggage("a", "b", context=context.get_current())
    new_ctx = baggage.set_baggage("c", "d", context=new_ctx)
    new_ctx = baggage.set_baggage("e", "f", context=new_ctx)
    context.attach(new_ctx)

    with tracer.start_as_current_span(name="child span"):
        print(baggage.get_all())

# >>> {'a': 'b', 'c': 'd', 'e': 'f'}

My expectations were similar in that:

1. Calling baggage.set_baggage would add the baggage to the current context right away.
2. ... and so baggage.get_all() always includes anything added by baggage.set_baggage up the span tree.
3. And if not that, that passing context=new_ctx would mean the baggage is taken up in the new span.

The third point is really surprising! It's actually that way for all context, right?

with tracer.start_as_current_span(name="root span"):
    new_ctx = context.set_value("a", "b")

    with tracer.start_as_current_span(name="child span", context=new_ctx):
        print(context.get_current().get("a"))

# >>> None (!?)

with tracer.start_as_current_span(name="root span"):
    new_ctx = context.set_value("a", "b")
    context.attach(new_ctx)

    with tracer.start_as_current_span(name="child span", context=new_ctx):
        print(context.get_current().get("a"))

# >>> b

Additional point on the API is that this means you have to chain passing the context if you have multiple baggage values to set which is a little cumbersome. 😄

[jhwbarlow]

For anyone else stumbling across this issue.

I'm using this as the cleanest way to set the baggage in the current span (i.e. what you would expect to be happening by default):

context.attach(baggage.set_baggage("foo", "bar"))

This is then passed through to child spans as you would expect.

[matejsp]

I got too stuck on understanding the baggage API. Examples are bad and very little explanation.

It is interesting that for opentracing shim it works a loot better (at least from code):
https://github.com/open-telemetry/opentelemetry-python/blob/main/shim/opentelemetry-opentracing-shim/src/opentelemetry/shim/opentracing_shim/__init__.py#L294

baggage is stored inside SpanContext and it is updated from set_baggate_item

 def set_baggage_item(self, key: str, value: str):
        self._context._baggage = set_baggage(
            key, value, context=self._context._baggage
        )

Any chance to get this fixed?

[aabmass]

Hey folks. I relabeled this from bug -> doc issue because everything is working as specified in the OTel spec: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/baggage/api.md Just to clarify, the Baggage APIs just thinly wrap the Context API.

---

@Knifa

I think this is further compounded because passing the created context=ctx to start_as_current_span doesn't actually attach to the context --- it's just used to grab the parent span.

Thanks for pointing this out, I think this might actually be a separate bug. I opened #3350. I think it would make the usability much better, then we can document the approach you outlined.

---

I'm using this as the cleanest way to set the baggage in the current span (i.e. what you would expect to be happening by default):

context.attach(baggage.set_baggage("foo", "bar"))

This is true, but I would be careful here as the token returned from context.attach() is being thrown away which can cause the baggage key you set to leak out. You should also do context.detach(token) (unfortunately we don't provide a context manager for this rn)

[omervk]

I hit the same issue. Whipped up a rudimentary context manager for it, in case anyone wants to use it:

@contextlib.contextmanager
def added_baggage(
    new_baggage: Optional[types.Attributes] = None,
    context: Optional[Context] = None,
):
    attached_context_tokens: list[object] = list()

    if new_baggage:
        for key, value in new_baggage.items():
            attached_token = baggage.set_baggage(key, value, context)
            attached_context_tokens.append(opentelemetry.context.attach(attached_token))

    try:
        yield
    finally:
        for attached_token in attached_context_tokens:
            opentelemetry.context.detach(attached_token)

Usage:

with added_baggage({ "foo": "bar" }):
    # ...

I recommend guarding it against failures, though, as telemetry code should (almost) never cause production code to fail.