Skip to content

1.8 Migration Guide

Jump to bottom
Tommy Ludwig edited this page Nov 2, 2026 · 5 revisions

OpenTelemetry Baggage Propagation Changes

In Micrometer Tracing 1.8.0, BaggageTextMapPropagator reads baggage from the OTel Context passed to inject, instead of BaggageManager.getAllBaggage() (#1617). Configured remote-field headers now use the same baggage as the W3C baggage header, whose behavior is unchanged.

Details

OtelPropagator.inject(TraceContext, …​) uses current OTel baggage for remote-field headers without adding or overriding values from baggage retained by the current TraceContext. Tracing identity still comes from the supplied TraceContext.

Baggage stored with a span by deprecated createBaggage(name, value) or Baggage.set(…​) calls is no longer injected unless it is also current. Use a baggage scope around the outgoing operation:

try (BaggageInScope baggage = tracer.createBaggageInScope("locale", "fr-FR")) {
    sendRequest();
}

The baggage must be current when headers are injected. For asynchronous work, propagate the context to that execution; see Context Propagation with Micrometer Tracing.

Non-deprecated APIs can also be affected when scoped and retained values differ. For example, a native OTel baggage scope overriding retained locale=en-US with fr-FR now sends fr-FR in both header formats (i.e., BaggageTextMapPropagator and W3CBaggagePropagator). The same applies to Micrometer baggage scopes targeting another span.

Constructor Deprecation

Prefer new BaggageTextMapPropagator(remoteFields). The two-argument constructor remains available but is deprecated, and its BaggageManager argument is ignored. Custom baggage-manager values must be present in the OTel context being injected.

OpenTelemetry Baggage Reads and Span Tags

Previously, retrieving baggage configured in tagFields on OtelBaggageManager could add a tag or overwrite an existing span attribute, even if the returned baggage handle was never used. Now, retrieving an existing baggage entry with tracer.getBaggage(name) no longer copies its value to the current span’s tags. The overload taking an explicit TraceContext did not have this side effect.

Configured baggage tags are applied when a baggage value is explicitly set or created in scope. Both createBaggageInScope(…​) overloads continue to tag the current span. Calling the no-argument makeCurrent() on an existing baggage handle does not tag any span, including handles obtained with getBaggage(traceContext, name). Closing the scope restores baggage; it does not restore the span’s previous tag value.

If application code relied on a baggage lookup to apply a tag, create the baggage in scope for the operation:

try (BaggageInScope baggage = tracer.createBaggageInScope("locale", locale)) {
    generateReport();
}

Alternatively, explicitly tag the span if no baggage scope is needed. For baggage already present when a span starts, including baggage extracted from incoming requests, configure a BaggageTaggingSpanProcessor on the OpenTelemetry SdkTracerProvider. The missing extracted-baggage tags reported in #933 were fixed by #1548; a baggage lookup is no longer needed as a workaround.

Clone this wiki locally