Skip to content

Export span links through native transport - #6129

Open
lloeki wants to merge 5 commits into
lloeki/native-libdatadog-payload-api-uptakefrom
lloeki/native-span-links-consumer
Open

Export span links through native transport#6129
lloeki wants to merge 5 commits into
lloeki/native-libdatadog-payload-api-uptakefrom
lloeki/native-span-links-consumer

Conversation

@lloeki

@lloeki lloeki commented Jul 30, 2026

Copy link
Copy Markdown
Member

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_hash payloads 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:

How to test the change?

  • Ran the native transport suite: 118 examples, 0 failures, including 128-bit IDs, flags, tracestate, flattened attributes, ordering, and mutation-safe snapshots.
  • Ran span-link and distributed propagation coverage: 83 examples, 0 failures, 1 existing pending example.
  • Ran the OpenTelemetry suite: 164 examples, 0 failures.
  • Ran Standard and Steep successfully.

@lloeki lloeki added the AI Generated Largely based on code generated by an AI or LLM. This label is the same across all dd-trace-* repos label Jul 30, 2026
@datadog-official

datadog-official Bot commented Jul 30, 2026

Copy link
Copy Markdown

Pipelines

⚠️ Warnings

🚦 3 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-rb | build-gem   View in Datadog   GitLab

DataDog/apm-reliability/dd-trace-rb | microbenchmarks: [other]   View in Datadog   GitLab

DataDog/apm-reliability/dd-trace-rb | microbenchmarks: [profiling]   View in Datadog   GitLab

Useful? React with 👍 / 👎

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 35294df | Docs | Datadog PR Page | Give us feedback!

@dd-octo-sts dd-octo-sts Bot added the tracing label Jul 30, 2026
@dd-octo-sts

dd-octo-sts Bot commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Thank you for updating Change log entry section 👏

Visited at: 2026-07-30 12:12:07 UTC

@lloeki
lloeki force-pushed the lloeki/native-libdatadog-next-uptake branch from 39c86b1 to 6fe683b Compare July 30, 2026 12:01
@lloeki
lloeki force-pushed the lloeki/native-span-links-consumer branch from 9e873ee to 20b9a60 Compare July 30, 2026 12:02
@lloeki
lloeki force-pushed the lloeki/native-span-links-consumer branch from 20b9a60 to 1d4a188 Compare August 3, 2026 14:54
@lloeki
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
lloeki force-pushed the lloeki/native-libdatadog-payload-api-uptake branch from a7ef512 to 703d524 Compare August 4, 2026 11:19
lloeki added 4 commits August 4, 2026 13:20
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
lloeki force-pushed the lloeki/native-span-links-consumer branch from 1893676 to 3bba941 Compare August 4, 2026 11:20
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
lloeki marked this pull request as ready for review August 4, 2026 14:08
@lloeki
lloeki requested review from a team as code owners August 4, 2026 14:08
@lloeki
lloeki requested review from mabdinur and marcotc and removed request for a team August 4, 2026 14:08
@p-datadog
p-datadog requested a review from Copilot August 4, 2026 19:00

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI Generated Largely based on code generated by an AI or LLM. This label is the same across all dd-trace-* repos tracing

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants