SDK-internal representation of a Span Link.
Mirrors the proto Span.Link message
(opentelemetry-proto/opentelemetry/proto/trace/v1/trace.proto
L252-L290) so the encoder can emit it 1:1, including the
dropped_attributes_count field that the OTel
common/mapping-to-non-otlp.md L75-L77 MUST requires per
data entity.
This struct is constructed by the SDK from the API-layer
Otel.API.Trace.Link at the moment limits are applied
(Otel.SDK.Trace.Span.add_link/2,
Otel.SDK.Trace.Span.start_span/6 for links provided at
creation time). Application code should not construct
this struct directly โ use %Otel.API.Trace.Link{...} and
pass the result to Otel.API.Trace.Span.add_link/2.
Why a separate SDK type?
Otel.API.Trace.Link (api.md L803-L834) defines a Link as
context + attributes. The dropped_attributes_count field
is an SDK / wire-format concern (proto field 5 on
Span.Link); placing it on the API struct would violate
the API โ SDK layer-independence rule in
.claude/rules/code-conventions.md.
References
- OTLP proto Span.Link:
opentelemetry-proto/opentelemetry/proto/trace/v1/trace.protoL252-L290 - OTel mapping spec:
opentelemetry-specification/specification/common/mapping-to-non-otlp.mdยง"Dropped Attributes Count" L73-L80
Summary
Types
@type primitive_any() :: primitive() | [primitive_any()] | %{required(String.t()) => primitive_any()}
@type t() :: %Otel.SDK.Trace.Link{ attributes: %{required(String.t()) => primitive_any()}, context: Otel.API.Trace.SpanContext.t(), dropped_attributes_count: non_neg_integer() }