Export span links through native transport - #6129
Open
lloeki wants to merge 5 commits into
Open
Conversation
This was referenced Jul 30, 2026
|
Contributor
|
Thank you for updating Change log entry section 👏 Visited at: 2026-07-30 12:12:07 UTC |
lloeki
force-pushed
the
lloeki/native-libdatadog-next-uptake
branch
from
July 30, 2026 12:01
39c86b1 to
6fe683b
Compare
lloeki
force-pushed
the
lloeki/native-span-links-consumer
branch
from
July 30, 2026 12:02
9e873ee to
20b9a60
Compare
This was referenced Jul 30, 2026
lloeki
force-pushed
the
lloeki/native-span-links-consumer
branch
from
August 3, 2026 14:54
20b9a60 to
1d4a188
Compare
lloeki
changed the base branch from
lloeki/native-libdatadog-next-uptake
to
lloeki/native-libdatadog-payload-api-uptake
August 3, 2026 14:55
gh-worker-dd-mergequeue-cf854d Bot
pushed a commit
to DataDog/libdatadog
that referenced
this pull request
Aug 4, 2026
AI-generated code disclosure: this PR was implemented with substantial AI assistance and manually reviewed and validated. # What does this PR do? Ensures the combined libdatadog profiling artifact enables `catch_panic` for data-pipeline FFI entry points. It also adds a packaged C regression that triggers capacity overflow and verifies that the FFI returns an error instead of aborting the process. # Motivation The standalone data-pipeline FFI crate enables panic containment by default, but the combined profiling artifact disables dependency defaults and did not re-enable it. This closes [APMSP-3830](https://datadoghq.atlassian.net/browse/APMSP-3830) before the native trace exporter payload APIs ship together. # Additional Notes **Stack position: L0, current PR: [DataDog/libdatadog PR 2302](#2302 These open L0-L5 changes are not included in [libdatadog v38.0.0](https://github.com/DataDog/libdatadog/releases/tag/v38.0.0). They are planned to ship together in a single libdatadog v39 release, with the common dd-trace-rb uptake tracked by [R3 DataDog/dd-trace-rb PR 6143](DataDog/dd-trace-rb#6143). Complete expected libdatadog review and merge order for that single v39 release: | Level | libdatadog PR | Matching dd-trace-rb consumer | | --- | --- | --- | | **L0 (current)** | **[DataDog/libdatadog PR 2302](#2302 | Release prerequisite; no payload API consumer | | L1 | [DataDog/libdatadog PR 2303](#2303) | [R4 DataDog/dd-trace-rb PR 6130](DataDog/dd-trace-rb#6130) | | L2 | [DataDog/libdatadog PR 2305](#2305) | [R5 DataDog/dd-trace-rb PR 6129](DataDog/dd-trace-rb#6129) | | L3 | [DataDog/libdatadog PR 2301](#2301) | [R6 DataDog/dd-trace-rb PR 6134](DataDog/dd-trace-rb#6134) | | L4 | [DataDog/libdatadog PR 2304](#2304) | [R7 DataDog/dd-trace-rb PR 6132](DataDog/dd-trace-rb#6132) | | L5 | [DataDog/libdatadog PR 2300](#2300) | [R8 DataDog/dd-trace-rb PR 6133](DataDog/dd-trace-rb#6133) | L0-L3 are independent and can be reviewed in parallel. Merging them in the listed order is still recommended because it reduces integration and release-branch conflicts, and lands panic containment before the new payload surfaces. L4 is stacked on L1, and L5 is stacked on L4. The matching payload consumers are [R4 DataDog/dd-trace-rb PR 6130](DataDog/dd-trace-rb#6130), [R5 DataDog/dd-trace-rb PR 6129](DataDog/dd-trace-rb#6129), [R6 DataDog/dd-trace-rb PR 6134](DataDog/dd-trace-rb#6134), [R7 DataDog/dd-trace-rb PR 6132](DataDog/dd-trace-rb#6132), and [R8 DataDog/dd-trace-rb PR 6133](DataDog/dd-trace-rb#6133). All depend through the common v39 uptake in [R3 DataDog/dd-trace-rb PR 6143](DataDog/dd-trace-rb#6143). The downstream review and merge order after R3 is R4, R5, R6, R7, then R8; R7 also depends on R4, and R8 depends on R7. [DataDog/libdatadog-rb v37 PR 65](DataDog/libdatadog-rb#65) and [DataDog/libdatadog-rb v38 PR 66](DataDog/libdatadog-rb#66) are separate ordered prerequisite releases only for [R2 DataDog/dd-trace-rb PR 6131](DataDog/dd-trace-rb#6131) and its `ForkSafeRuntime` uptake. They do not contain the open L0-L5 changes or payload APIs. R3 is stacked on R2, but R3, rather than either prerequisite package, is the common v39 payload-API uptake. L0 tracks [APMSP-3830](https://datadoghq.atlassian.net/browse/APMSP-3830); L1-L5 implement the payload work tracked by [APMSP-3219](https://datadoghq.atlassian.net/browse/APMSP-3219). # How to test the change? Prior local validation completed successfully: - `nix develop -c cargo test -p libdd-profiling-ffi --features data-pipeline-ffi` passed the combined profiling/data-pipeline FFI suite: 57 tests. - `nix develop -c cargo test -p libdd-data-pipeline-ffi --features catch_panic trace_chunks_new_with_overflow_capacity_returns_panic_error` passed. - `nix develop -c cargo test -p libdd-data-pipeline-ffi --features catch_panic begin_chunk_with_overflow_capacity_returns_panic_error` passed. - `nix develop -c cargo ffi-test --filter trace_exporter_panic_containment` built and passed the packaged C panic-containment regression. - `nix develop .#nightly --command cargo fmt --all -- --check` passed. - `nix develop -c cargo clippy -p libdd-profiling-ffi --all-targets --features data-pipeline-ffi -- -D warnings` passed. [APMSP-3830]: https://datadoghq.atlassian.net/browse/APMSP-3830?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [APMSP-3830]: https://datadoghq.atlassian.net/browse/APMSP-3830?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ Co-authored-by: ekump <edmund.kump@datadoghq.com> Co-authored-by: hoolioh <julio.gonzalez@datadoghq.com>
lloeki
force-pushed
the
lloeki/native-libdatadog-payload-api-uptake
branch
from
August 4, 2026 11:19
a7ef512 to
703d524
Compare
Normalize each link through `SpanLink#to_hash`, validate its canonical fields, and pass the complete ordered link batch to libdatadog. This keeps OpenTelemetry and distributed propagation semantics consistent when traces use the native transport. Stop warning about span links now that their IDs, attributes, tracestate, and flags are preserved on the wire.
Canonical link hashes may use stateful defaults or mutate borrowed Ruby strings. Copy every field and string byte exactly once before allocating the Rust span so later Ruby callbacks cannot invalidate FFI pointers or produce an internally inconsistent link. Own partial snapshots explicitly so exceptions during normalization release every C allocation before propagating back to Ruby.
Preserve `dropped_attributes_count` from the canonical link format so native exports retain the complete link contract. Delay borrowing scalar span string pointers until link normalization has finished because `SpanLink#to_hash` can run Ruby code that mutates or relocates those strings.
Remove native extraction and FFI forwarding for `dropped_attributes_count`. Neither the Agent v0.4 nor indexed V1 span-link schema defines this field, and current Datadog tracers do not produce non-zero counts. The historical pure-Ruby `SpanLink#to_hash` scaffold remains unchanged. This additive commit can be reverted when the Agent protocols formally allocate and support the field.
lloeki
force-pushed
the
lloeki/native-span-links-consumer
branch
from
August 4, 2026 11:20
1893676 to
3bba941
Compare
gh-worker-dd-mergequeue-cf854d Bot
pushed a commit
to DataDog/libdatadog
that referenced
this pull request
Aug 4, 2026
AI-generated code disclosure: this PR was implemented with substantial AI assistance and manually reviewed and validated. # What does this PR do? Adds an opaque per-key `meta_struct` blob setter to `TracerSpan`. Keys are validated as UTF-8, while values are copied as uninterpreted binary data. This transitional API lets consumers pass their existing per-key MessagePack blobs without changing the Rust trace model. # Motivation Native exporter consumers cannot currently populate `meta_struct`, which blocks payload parity tracked by [APMSP-3219](https://datadoghq.atlassian.net/browse/APMSP-3219). The opaque setter provides the safe first stage before the language-neutral structured-value APIs. # Additional Notes **Stack position: L1, current PR: [DataDog/libdatadog PR 2303](#2303 These open L0-L5 changes are not included in [libdatadog v38.0.0](https://github.com/DataDog/libdatadog/releases/tag/v38.0.0). They are planned to ship together in a single libdatadog v39 release, with the common dd-trace-rb uptake tracked by [R3 DataDog/dd-trace-rb PR 6143](DataDog/dd-trace-rb#6143). Complete expected libdatadog review and merge order for that single v39 release: | Level | libdatadog PR | Matching dd-trace-rb consumer | | --- | --- | --- | | L0 | [DataDog/libdatadog PR 2302](#2302) | Release prerequisite; no payload API consumer | | **L1 (current)** | **[DataDog/libdatadog PR 2303](#2303 | **[R4 DataDog/dd-trace-rb PR 6130](DataDog/dd-trace-rb#6130 | | L2 | [DataDog/libdatadog PR 2305](#2305) | [R5 DataDog/dd-trace-rb PR 6129](DataDog/dd-trace-rb#6129) | | L3 | [DataDog/libdatadog PR 2301](#2301) | [R6 DataDog/dd-trace-rb PR 6134](DataDog/dd-trace-rb#6134) | | L4 | [DataDog/libdatadog PR 2304](#2304) | [R7 DataDog/dd-trace-rb PR 6132](DataDog/dd-trace-rb#6132) | | L5 | [DataDog/libdatadog PR 2300](#2300) | [R8 DataDog/dd-trace-rb PR 6133](DataDog/dd-trace-rb#6133) | L0-L3 are independent and can be reviewed in parallel. Merging them in the listed order is still recommended because it reduces integration and release-branch conflicts, and lands panic containment before the new payload surfaces. L4 is stacked on L1, and L5 is stacked on L4. The matching payload consumers are [R4 DataDog/dd-trace-rb PR 6130](DataDog/dd-trace-rb#6130), [R5 DataDog/dd-trace-rb PR 6129](DataDog/dd-trace-rb#6129), [R6 DataDog/dd-trace-rb PR 6134](DataDog/dd-trace-rb#6134), [R7 DataDog/dd-trace-rb PR 6132](DataDog/dd-trace-rb#6132), and [R8 DataDog/dd-trace-rb PR 6133](DataDog/dd-trace-rb#6133). All depend through the common v39 uptake in [R3 DataDog/dd-trace-rb PR 6143](DataDog/dd-trace-rb#6143). The downstream review and merge order after R3 is R4, R5, R6, R7, then R8; R7 also depends on R4, and R8 depends on R7. [DataDog/libdatadog-rb v37 PR 65](DataDog/libdatadog-rb#65) and [DataDog/libdatadog-rb v38 PR 66](DataDog/libdatadog-rb#66) are separate ordered prerequisite releases only for [R2 DataDog/dd-trace-rb PR 6131](DataDog/dd-trace-rb#6131) and its `ForkSafeRuntime` uptake. They do not contain the open L0-L5 changes or payload APIs. R3 is stacked on R2, but R3, rather than either prerequisite package, is the common v39 payload-API uptake. L0 tracks [APMSP-3830](https://datadoghq.atlassian.net/browse/APMSP-3830); L1-L5 implement the payload work tracked by [APMSP-3219](https://datadoghq.atlassian.net/browse/APMSP-3219). # How to test the change? Prior local validation completed successfully: - `nix develop -c cargo test -p libdd-data-pipeline-ffi` passed, including arbitrary binary values, overwrite semantics, null handles, and invalid UTF-8 keys. - `nix develop -c cargo clippy -p libdd-data-pipeline-ffi --all-targets -- -D warnings` passed. - `nix develop .#nightly -c cargo fmt --all -- --check` passed. - The generated C header was rebuilt through `nix develop -c cargo run --bin release -- --out /tmp/opencode/native-meta-struct-libdatadog/x86_64-linux` and consumed successfully by the matching dd-trace-rb branch. - `nix develop .#ruby34 --command bundle exec rspec spec/datadog/tracing/transport/native/tracer_span_spec.rb spec/datadog/tracing/transport/native/conformance_spec.rb spec/datadog/tracing/transport/native/transport_spec.rb spec/datadog/appsec/actions_handler/serializable_backtrace_spec.rb` passed 116 examples, including AppSec and AI Guard-shaped wire conformance. - Targeted Standard and Steep checks for the native transport passed. [APMSP-3219]: https://datadoghq.atlassian.net/browse/APMSP-3219?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [APMSP-3830]: https://datadoghq.atlassian.net/browse/APMSP-3830?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ Co-authored-by: ekump <edmund.kump@datadoghq.com> Co-authored-by: loic.nageleisen <loic.nageleisen@datadoghq.com>
lloeki
marked this pull request as ready for review
August 4, 2026 14:08
lloeki
requested review from
mabdinur and
marcotc
and removed request for
a team
August 4, 2026 14:08
There was a problem hiding this comment.
Pull request overview
This PR adds native-transport support for exporting span links by snapshotting canonical SpanLink#to_hash data in the C extension and wiring it into ddog_tracer_span_set_links, with accompanying spec updates to validate wire conformance, ordering, and mutation-safety.
Changes:
- Add span-link snapshotting and FFI conversion in
ext/libdatadog_api/trace_exporter.c, then set links on the Rust span during native conversion. - Update native transport warning logic to stop warning on span links (now supported) and adjust related transport specs.
- Add/extend conformance and integration specs to assert canonical link hashes, ordering, and behavior under mutation/default-proc hazards.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| spec/datadog/tracing/transport/native/transport_spec.rb | Updates warning expectations now that native transport supports span links. |
| spec/datadog/tracing/transport/native/tracer_span_spec.rb | Adds native conversion behavior tests for span-link normalization, UTF-8 rejection, and snapshot cleanup. |
| spec/datadog/tracing/transport/native/conformance_spec.rb | Adds on-the-wire conformance checks for span-link payload content and ordering. |
| spec/datadog/tracing/distributed/propagation_spec.rb | Extends propagation coverage to assert SpanLink#to_hash output for extracted context. |
| spec/datadog/opentelemetry_spec.rb | Adds explicit assertions for OpenTelemetry link translation into canonical to_hash payloads. |
| lib/datadog/tracing/transport/native.rb | Removes “unsupported span links” warning path and updates commentary to reflect new support. |
| ext/libdatadog_api/trace_exporter.c | Implements C-side snapshotting of canonical span-link hashes and exports them via libdatadog setters. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+423
to
+426
| it "does not warn when a span carries span links" do | ||
| link = Datadog::Tracing::SpanLink.new( | ||
| Datadog::Tracing::TraceDigest.new(trace_id: 1, span_id: 2) | ||
| ) |
Comment on lines
+578
to
+588
| VALUE rb_links = rb_ivar_get(span, at_links_id); | ||
| ENFORCE_TYPE(rb_links, T_ARRAY); | ||
| span_links_snapshot links_snapshot = { | ||
| .rb_links = rb_links, | ||
| }; | ||
| int snapshot_state = 0; | ||
| rb_protect(prepare_span_links_snapshot, (VALUE)&links_snapshot, &snapshot_state); | ||
| if (snapshot_state) { | ||
| free_span_links_snapshot(&links_snapshot); | ||
| rb_jump_tag(snapshot_state); | ||
| } |
Keep libdatadog UTF-8 validation consistent with native meta handling, but make the resulting whole-batch failure explicit. Cover the transport response and clarify which canonical link fields the wire format supports.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
AI-generated code disclosure: this PR was implemented with substantial AI assistance and manually reviewed and validated.
What does this PR do?
Exports canonical
SpanLink#to_hashpayloads through the native transport, including 128-bit IDs, flags, tracestate, flattened attributes, and ordering. Snapshot conversion prevents Ruby mutation and default-proc hazards during native conversion.Motivation:
Native trace export currently omits span links. This adds payload parity for distributed tracing and OpenTelemetry link data as part of APMSP-3219.
Change log entry
Yes. Native trace export now supports span links.
Additional Notes:
dropped_attributes_countis intentionally deferred by additive commit 1893676d. The Agent v0.4 and indexed V1 schemas do not define it, and the existing Ruby field never produces a non-zero value. Reverting this commit restores the native wiring.How to test the change?