The current OTel Baggage structure is backed by a HashMap, which does not preserve ordering of baggage entries.
In our usage, during LogProcessor/SpanProcessor execution, we project baggage key–value pairs into log/span attributes (LogData/SpanData). Because the baggage ordering is not always consistent, the resulting attributes can appear in different orders across emissions. This may become problematic in scenarios where downstream systems rely on stable attribute ordering.
Would it be worth considering (or opening a discussion about) an alternative OpenTelemetry Baggage structure that provides deterministic ordering?
This could be gated as an opt‑in feature for users who rely on consistent ordering (given that OTel Rust internally uses vec/[] for attributes).
cc: @cijothomas
The current OTel Baggage structure is backed by a HashMap, which does not preserve ordering of baggage entries.
In our usage, during LogProcessor/SpanProcessor execution, we project baggage key–value pairs into log/span attributes (LogData/SpanData). Because the baggage ordering is not always consistent, the resulting attributes can appear in different orders across emissions. This may become problematic in scenarios where downstream systems rely on stable attribute ordering.
Would it be worth considering (or opening a discussion about) an alternative OpenTelemetry Baggage structure that provides deterministic ordering?
This could be gated as an opt‑in feature for users who rely on consistent ordering (given that OTel Rust internally uses vec/[] for attributes).
cc: @cijothomas