Skip to content

fix(logs): use handler span id for log correlation in X-Ray mode - #88

Open
dash0-app[bot] wants to merge 1 commit into
masterfrom
fix/log-span-backlink-xray-mode
Open

fix(logs): use handler span id for log correlation in X-Ray mode#88
dash0-app[bot] wants to merge 1 commit into
masterfrom
fix/log-span-backlink-xray-mode

Conversation

@dash0-app

@dash0-app dash0-app Bot commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Summary

When DASH0_XRAY_TRACES_ENABLED=true, the extension skips emitting supplementary spans (root span, init span). A root_span_id is still generated during handle_invoke_event, but the corresponding span is never exported to the backend.

Previously get_trace_span_ids_for_logs always stamped logs with root_span_id. Because no span with that id exists in the backend, Dash0 showed the error This log record has a trace context, but the referenced span could not be found whenever a user opened a log record from the Span Context panel.

Changes

  • get_trace_span_ids_for_logs now returns span_id (the handler span from the OTel instrumentation layer) instead of root_span_id when X-Ray mode is active.
  • In the standard path the existing behaviour is preserved (root_span_id takes priority), with a new fallback to span_id for the early-arrival window before root_span_id is populated.
  • Three new unit tests cover: standard mode (root_span_id present), standard mode fallback (root_span_id absent), and X-Ray mode.

Context

When DASH0_XRAY_TRACES_ENABLED=true, the extension skips creating
supplementary spans (root span and init span). As a result, root_span_id
is generated during handle_invoke_event but the corresponding span is
never exported to the backend.

Previously, get_trace_span_ids_for_logs always stamped logs with
root_span_id, which caused the 'referenced span could not be found'
error when opening a log record from the Span Context panel — the
span id encoded in the log did not match any exported span.

Fix: in X-Ray mode, use span_id (the handler span emitted by the OTel
instrumentation layer) instead of root_span_id, since that span is
always present in the trace.

In the standard (non-X-Ray) path the behaviour is unchanged: logs are
correlated to root_span_id (the supplementary root span), with a new
fallback to span_id in case root_span_id has not yet been populated.

Fixes SUP-1560
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant