feat(telemetry)!: make telemetry worker wasm-compatible for the TraceExporter

[Aaalibaba42]

What?

Port the telemetry stack (libdd-telemetry, libdd-data-pipeline) to compile and run on wasm32-unknown-unknown. TelemetryWorker, TelemetryWorkerHandle, and TelemetryClient become generic over a capability bundle C: HttpClientCapability + SleepCapability; native call sites pin to NativeCapabilities.

Why?

Telemetry was previously hard-gated behind #[cfg(not(target_arch = "wasm32"))] and was a no-op on that target for the TraceExporter.

How?

• Every tokio::time call (sleep, timeout) is replaced by a tokio::select! race against <C as SleepCapability>::new().sleep(…), which resolves to setTimeout on wasm.
• std::time replaced by web-time (Performance.now() / Date.now() on wasm, re-exports std::time on native).
• Shutdown signaling adds a tokio::sync::Notify-based async path alongside the existing native Condvar sync path.
• The old MockClient/file-endpoint logic in http_client.rs is deleted and ported to NativeCapabilities in libdd-capabilities-impl.

Additional Notes

• TelemetryClientBuilder::build now returns Result (was panicking on missing fields) — Rust API break.
• TelemetryClient::start is now sync via try_send_msg — Rust API break.
• FFI and sidecar crates are unaffected at the ABI level; they use a local type alias pinned to NativeCapabilities.

[datadog-official]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 71.60%
• Overall Coverage: 74.57% (-0.07%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 19987a1 | Docs | Datadog PR Page | Give us feedback!}

[github-actions]

Clippy Allow Annotation Report

Tracked Clippy allow annotations changed vs main: ✅ -6 (31 → 25)

Rule	Base	PR	Δ
expect_used	3	0	✅ -3
unwrap_used	28	25	✅ -3

By file and crate

By file

File	Base	PR	Δ
libdd-data-pipeline/src/telemetry/mod.rs	1	0	✅ -1
libdd-telemetry/src/worker/http_client.rs	3	0	✅ -3
libdd-telemetry/src/worker/mod.rs	14	12	✅ -2

By crate

Crate	Base	PR	Δ
libdd-data-pipeline	6	5	✅ -1
libdd-telemetry	20	15	✅ -5

About This Report

This report tracks Clippy allow annotations for specific rules, showing how they've changed in this PR. Decreasing the number of these annotations generally improves code quality. Panic-inducing macros in particular should be avoided. In the future, this report may become a PR-blocking quality gate.

[VianneyRuhlmann]

The change in shutdown_worker really needs to be discussed further as it can negatively impact shutdown time. Also a lot of comment are very verbose and at wasm specific explanation on public methods doc that shouldn't be cluttered with implementation details.

[Aaalibaba42]

The change in shutdown_worker really needs to be discussed further as it can negatively impact shutdown time

We can always have the previous native implementation as is in a #[cfg(not(target_arch="wasm32"))] to make sure we have no impact on native

[pr-commenter]

Benchmarks

Comparison

Benchmark execution time: 2026-07-18 05:31:50

Comparing candidate commit 19987a1 in PR branch jwiriath/telemetry-wasm with baseline commit d7980db in branch main.

Found 2 performance improvements and 0 performance regressions! Performance is the same for 140 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:vec_map/get_mut/8

• 🟩 execution_time [-10.093ns; -5.275ns] or [-10.894%; -5.695%]
• 🟩 throughput [+5367539.310op/s; +10312627.283op/s] or [+6.097%; +11.713%]

Benchmark execution time: 2026-07-18 05:45:46

Comparing candidate commit 19987a1 in PR branch jwiriath/telemetry-wasm with baseline commit d7980db in branch main.

Found 5 performance improvements and 0 performance regressions! Performance is the same for 172 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/sampled_system_fast_path/4096

• 🟩 execution_time [-21.311ns; -21.169ns] or [-18.281%; -18.160%]

scenario:alloc_free/sampled_system_slow_path/4096

• 🟩 execution_time [-10.369ns; -10.243ns] or [-6.571%; -6.492%]

scenario:alloc_free/system/4096

• 🟩 execution_time [-12.615ns; -12.458ns] or [-11.814%; -11.667%]

scenario:trace_buffer/4_senders/no_delay

• 🟩 execution_time [-157.772µs; -130.414µs] or [-6.334%; -5.236%]
• 🟩 throughput [+79978.458op/s; +96939.607op/s] or [+5.529%; +6.701%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

[dd-octo-sts]

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	7.95 MB	8.13 MB	+2.35% (+191.85 KB) ⚠️
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	86.47 MB	88.03 MB	+1.80% (+1.55 MB) ⚠️

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.69 MB	10.86 MB	+1.67% (+183.03 KB) ⚠️
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	97.68 MB	99.31 MB	+1.67% (+1.63 MB) ⚠️

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	25.62 MB	26.55 MB	+3.63% (+954.50 KB) ⚠️
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	89.18 KB	89.18 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	186.36 MB	191.09 MB	+2.54% (+4.73 MB) ⚠️
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	962.77 MB	1.04 GB	+10.85% (+104.52 MB) 🚨
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	8.38 MB	8.65 MB	+3.25% (+279.00 KB) ⚠️
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	89.18 KB	89.18 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	24.80 MB	25.31 MB	+2.07% (+528.00 KB) ⚠️
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	49.36 MB	50.49 MB	+2.29% (+1.13 MB) ⚠️

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	22.27 MB	23.13 MB	+3.86% (+881.50 KB) ⚠️
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	90.58 KB	90.58 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	190.82 MB	195.82 MB	+2.62% (+5.00 MB) ⚠️
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	950.99 MB	1.03 GB	+11.06% (+105.25 MB) 🚨
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	6.48 MB	6.67 MB	+2.98% (+198.50 KB) ⚠️
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	90.58 KB	90.58 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	26.62 MB	27.22 MB	+2.22% (+608.00 KB) ⚠️
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	46.97 MB	48.06 MB	+2.33% (+1.09 MB) ⚠️

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	77.21 MB	78.53 MB	+1.70% (+1.31 MB) ⚠️
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	8.84 MB	9.04 MB	+2.33% (+211.87 KB) ⚠️

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	92.63 MB	94.02 MB	+1.49% (+1.38 MB) ⚠️
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.75 MB	11.00 MB	+2.33% (+257.24 KB) ⚠️

[Aaalibaba42]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-07-20 13:00:54 UTC ℹ️ Start processing command /merge

---

2026-07-20 13:00:59 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in main is approximately 1h (p90).

---

2026-07-20 13:43:54 UTC ❌ MergeQueue: The checks failed on this merge request

Tests failed on this commit ed87d17:

• Test x86_64-unknown-linux-gnu on centOS7 docker image
• run-miri (3)
• run-miri (4)
• run-miri (2)
• run-miri (5)
  ...

What to do next?

• Investigate the failures and when ready, re-add your pull request to the queue!
• If your PR checks are green, try to rebase/merge. It might be because the CI run is a bit old.
• Any question, go check the FAQ.

[Aaalibaba42]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-07-20 13:44:37 UTC ℹ️ Start processing command /merge

---

2026-07-20 13:44:41 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in main is approximately 1h (p90).

---

2026-07-20 14:34:04 UTC ℹ️ MergeQueue: Readding this merge request to the queue because another merge request processed with yours failed. No action is needed from your side.

---

2026-07-20 15:20:03 UTC ℹ️ MergeQueue: This merge request was merged