You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
BB-764: All Kafka consumers use span Links, never parent-child
Convention: every Kafka consumer read starts a new root trace and adds
an OTEL Link to the upstream span from the message headers. No Kafka
hop uses parent-child. Rationale:
- Async work (replication, lifecycle, GC, notifications) can fire
minutes to hours after the original S3 request. Parent-child puts
both in one trace → huge wall-clock gap in the waterfall, traces with
millions of spans for high-volume buckets.
- Links keep each trace small and focused. Jaeger renders them as
clickable cross-trace jumps.
- OTEL messaging semantic conventions recommend links for async hops
with significant time gaps.
Changes:
- BackbeatConsumer._processTask always calls startLinkedSpanFromKafkaEntry.
Removed entryHasLinkHeaders auto-detect and the parent-child code path.
- kafkaTraceContext.js simplified: removed linkHeadersFromCurrentContext()
and linkContextFromKafkaHeaders(). startLinkedSpanFromKafkaEntry now
reads standard traceparent/tracestate. startSpanFromKafkaEntry kept
as backward-compat alias (same function ref).
- Producer-side: LifecycleTask.js and ReplicationAPI.js switched from
linkHeadersFromCurrentContext() to traceHeadersFromCurrentContext()
(same output, just standard traceparent headers).
Issue: BB-764
0 commit comments