Context

PR #3482 stabilized tracing-span attribute enrichment in opentelemetry-appender-tracing. With enrichment enabled, attributes from active tracing::span!s are copied onto each emitted log record alongside the event's own fields.

This raises the probability of duplicate attribute keys in a single log record:

• A key set on a tracing::span! can collide with a field on the inner tracing::event!.
• The same key on a parent and a child span will both be copied.

Today the appender appends in deterministic order (root → leaf → event) and relies on the SDK to handle duplicates. The SDK does not do this either today (tracked in #3497).

Proposal

Independently of the SDK-level fix, give the appender a configuration knob to control collision behavior on the enrichment path specifically — for users who want guaranteed-unique keys without paying the dedup cost on every other code path.

Strawman:

pub enum SpanAttributeCollisionPolicy {
    /// Append in root → leaf → event order; let the SDK handle dedup. (default)
    AppendInOrder,
    /// Last-write-wins: event > leaf > root.
    LastWins,
}

OpenTelemetryTracingBridge::builder(&provider)
    .with_span_attributes(SpanAttributes::all())
    .with_span_attribute_collision_policy(SpanAttributeCollisionPolicy::LastWins)
    .build();

Open questions:

• Whether this is needed at all once Logs SDK: deduplicate LogRecord attribute keys #3497 lands (it may be redundant).
• Naming and exact semantics of each variant.
• Whether to apply only to span-vs-event collisions, only to span-vs-span, or both.

Refs

• PR feat(appender-tracing): stabilize span attribute propagation #3482 — feature stabilization: feat(appender-tracing): stabilize span attribute propagation #3482
• Discussion that surfaced this: feat(appender-tracing): stabilize span attribute propagation #3482 (comment)
• Related: Logs SDK: deduplicate LogRecord attribute keys #3497 (SDK-level dedup)