feat(data-pipeline): add fork-safe OTLP gRPC trace transport

[bm1549]

What does this PR do?

Adds a plaintext gRPC-over-HTTP/2 (h2c) trace-export transport for OTLP to libdd-data-pipeline. It's a custom GrpcService (H2Service) plugged into tonic's generic Grpc<T> client, so the exporter holds no persistent connection or background task: each send opens a fresh connection driven by per-request tasks that are torn down when the send completes.

This is the transport primitive only. The OTLP export path is wired to it in a follow-up PR that rebases on top of this one.

Motivation

The earlier OTLP gRPC approach built a tonic Channel, which spawns a persistent background task. Because libdatadog rebuilds its runtime across fork(2), that task dies silently after a fork, which forced a Worker plus watch channel to rebuild it. Making the transport per-request and task-free removes that machinery and is fork-safe by construction.

Additional Notes

• default-features = false on tonic (no transport, channel, or server); a minimal prost codec replaces ProstCodec, which moved to the separate tonic-prost crate.
• Plaintext only: https:// endpoints are rejected at build time; terminate TLS in a proxy in front of the endpoint if encryption is needed.
• Deferred to the wiring PR: retry parity with the HTTP path, default-port handling for portless endpoints, and preserving the gRPC status code in the error mapping.

How to test the change?

• cargo nextest run -p libdd-data-pipeline covers unit tests plus in-process h2 integration tests: a real unary send decoded by a mock gRPC server, and connection-refused, timeout, and post-connect-reset cases that all map to TraceExporterError::Io.
• Run cargo clippy -p libdd-data-pipeline --all-targets -- -D warnings, cargo +nightly-2026-07-26 fmt --all -- --check, and cargo check -p libdd-data-pipeline --target wasm32-unknown-unknown --no-default-features.

[datadog-datadog-prod-us1-2]

✅ All CI checks and tests passed.

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 94.03%
• Overall Coverage: 76.82% (+0.10%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 1f2c50a | Docs | View more details | Give us feedback!}

[dd-octo-sts]

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	89.74 MB	90.19 MB	+.49% (+454.58 KB) 🔍
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	8.26 MB	8.33 MB	+.76% (+64.46 KB) 🔍

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	100.97 MB	101.49 MB	+.51% (+531.02 KB) 🔍
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	11.13 MB	11.16 MB	+.22% (+25.10 KB) 🔍

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	26.68 MB	26.94 MB	+1.00% (+273.50 KB) ⚠️
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	94.96 KB	94.96 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	181.16 MB	184.58 MB	+1.88% (+3.42 MB) ⚠️
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	770.91 MB	807.34 MB	+4.72% (+36.42 MB) ⚠️
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	8.75 MB	8.80 MB	+.65% (+58.50 KB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	94.96 KB	94.96 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	25.70 MB	25.84 MB	+.54% (+144.00 KB) 🔍
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	51.17 MB	51.45 MB	+.54% (+284.29 KB) 🔍

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	23.25 MB	23.48 MB	+1.00% (+238.50 KB) ⚠️
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	96.45 KB	96.45 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	186.11 MB	189.58 MB	+1.86% (+3.47 MB) ⚠️
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	756.49 MB	788.08 MB	+4.17% (+31.58 MB) ⚠️
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	6.76 MB	6.81 MB	+.74% (+51.50 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	96.45 KB	96.45 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	27.64 MB	27.79 MB	+.53% (+152.00 KB) 🔍
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	48.71 MB	49.00 MB	+.58% (+291.43 KB) 🔍

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	80.03 MB	80.43 MB	+.50% (+411.15 KB) 🔍
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	9.18 MB	9.24 MB	+.60% (+56.46 KB) 🔍

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	95.76 MB	96.19 MB	+.45% (+446.43 KB) 🔍
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	11.20 MB	11.27 MB	+.68% (+78.77 KB) 🔍

[pr-commenter]

Benchmarks

Comparison

Benchmark execution time: 2026-08-28 13:40:21

Comparing candidate commit 1f2c50a in PR branch brian.marks/otlp-grpc-transport with baseline commit 86bd486 in branch main.

Found 2 performance improvements and 0 performance regressions! Performance is the same for 151 metrics, 0 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:msgpack_decoder::v05/high_sharing/2000

• 🟩 execution_time [-90.656µs; -90.124µs] or [-5.513%; -5.480%]
• 🟩 throughput [+70528.610op/s; +70943.439op/s] or [+5.799%; +5.833%]

Benchmark execution time: 2026-08-28 13:46:58

Comparing candidate commit 1f2c50a in PR branch brian.marks/otlp-grpc-transport with baseline commit 86bd486 in branch main.

Found 1 performance improvements and 2 performance regressions! Performance is the same for 165 metrics, 10 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:alloc_free/system/4096

• 🟩 execution_time [-26.935ns; -26.792ns] or [-29.498%; -29.342%]

scenario:datadog_sample_span/unicode_uppercase_service_rule/wall_time

• 🟥 execution_time [+15.778ns; +15.938ns] or [+4.539%; +4.585%]

scenario:profiler_attached/fast_path_system/4096

• 🟥 execution_time [+8.618ns; +8.796ns] or [+8.941%; +9.126%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

[yannham]

Overall LGTM, nothing major blocking.

Though the same caveat as in the original PR applies about the size issue:

A first naive question: could/should this be feature-gated? I assume you'd want all tracers to support otlp out of the box, so the answers might be no, bu asking just > in case.

A good test for the impact of the binary size increase: would you mind trying to create a PR against dd-trace-py pointing to this PR's libdatadog ref, and see if it triggers the size gates for e.g. serverless?

[mabdinur]

Reviewed the OTLP gRPC transport and follow-up fixes. All review threads are resolved, local validation passes, and all CI checks are green on ad17de3.

[yannham]

I am still worrying about the binary size explosion, which could trigger SLOs on the serverless side, as quoted in #2273 (review). Has any of the suggestions been tried (either feature gating if possible, or trying the little experiment to see if it triggers a binary size SLO down the line)?

[bm1549]

I am still worrying about the binary size explosion, which could trigger SLOs on the serverless side, as quoted in #2273 (review). Has any of the suggestions been tried (either feature gating if possible, or trying the little experiment to see if it triggers a binary size SLO down the line)?

@yannham just confirmed that dd-trace-py is still under the limit after adding in this dependency DataDog/dd-trace-py#19971

[yannham]

Great, thanks for checking. Review suggestion implementation LGTM