Skip to content

feat(data-pipeline): add runtime-independent agentless sending - #2389

Open
rochdev wants to merge 6 commits into
mainfrom
rochdev/host-managed-data-pipeline
Open

feat(data-pipeline): add runtime-independent agentless sending#2389
rochdev wants to merge 6 commits into
mainfrom
rochdev/host-managed-data-pipeline

Conversation

@rochdev

@rochdev rochdev commented Aug 21, 2026

Copy link
Copy Markdown
Member

What does this PR do?

Adds a runtime-independent agentless data-pipeline send path. Rust owns trace
preparation, JSON encoding, compression, retry policy, timeouts, backoff, and
response handling; the host provides only HTTP and sleep capabilities.

The existing libdd-data-pipeline exporter now uses the same high-level send
path, so native and WASM consumers share the behavior without requiring a
specific async runtime.

Motivation

Node.js needs equivalent native and WASM data-pipeline implementations without
embedding Tokio and Hyper in the native extension. Keeping the send lifecycle
in Rust preserves retry behavior and makes the capability boundary reusable by
future targets.

Additional Notes

  • Request bodies are compressed once before the retry loop.
  • Native HTTP/runtime dependencies remain optional.
  • Node-specific v0.4 trace decoding remains in libdatadog-nodejs.

This PR was generated by Codex.

How to test the change?

  • cargo test -p libdd-data-pipeline-core --features compression
  • cargo test -p libdd-trace-utils send_with_retry
  • cargo test -p libdd-data-pipeline agentless
  • cargo clippy -p libdd-data-pipeline-core --all-targets --features compression -- -D warnings
  • cargo clippy -p libdd-trace-utils --lib --tests -- -D warnings
  • cargo clippy -p libdd-data-pipeline --lib -- -D warnings

@github-actions

github-actions Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 3141 documentation warning(s) found

📦 libdd-capabilities-impl - 209 warning(s)

📦 libdd-common - 169 warning(s)

📦 libdd-data-pipeline-core - 715 warning(s)

📦 libdd-data-pipeline - 1283 warning(s)

📦 libdd-http-client - ✅ No warnings

📦 libdd-trace-utils - 765 warning(s)


Updated: 2026-08-26 03:48:22 UTC | Commit: 991cd22 | missing-docs job results

@datadog-prod-us1-3

datadog-prod-us1-3 Bot commented Aug 21, 2026

Copy link
Copy Markdown

Tests

All CI checks and tests passed.

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
Patch Coverage: 88.89%
Overall Coverage: 76.72% (+0.07%)

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

@github-actions

github-actions Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

⚠️ 19 issue(s) found, showing only errors (advisories, bans, sources)

📦 libdd-capabilities-impl - 1 error(s)

Show output
error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:74:1
   │
74 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2026-0097
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
   ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
     
     - The `log` and `thread_rng` features are enabled
     - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
     - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
     - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
     - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
     
     `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
   ├ Announcement: https://github.com/rust-random/rand/pull/1763
   ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
   ├ rand v0.8.5
     ├── (dev) libdd-common v5.2.0
     │   └── libdd-capabilities-impl v4.0.0
     └── proptest v1.5.0
         └── (dev) libdd-common v5.2.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-common - 4 error(s)

Show output
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:35:1
   │
35 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     ├── crossbeam-deque v0.8.5
     │   └── rayon-core v1.12.1
     │       └── rayon v1.10.0
     │           └── criterion v0.5.1
     │               └── libdd-common v5.2.0
     └── moka v0.12.13
         └── hickory-resolver v0.25.2
             └── reqwest v0.13.2
                 └── libdd-common v5.2.0 (*)

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:65:1
   │
65 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0118
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0118
   ├ The NSEC3 closest-encloser proof validation in `hickory-proto`'s
     `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a
     list of candidate encloser names. The iterator used assumes the
     QNAME is a descendant of the SOA owner, terminating only when the current
     candidate equals the SOA name. When the SOA in a response's authority section
     is not an ancestor of the QNAME, the loop stalls at the DNS root and never
     terminates, repeatedly calling `Name::base_name()` and pushing newly allocated
     `Name` and hashed-name entries into the candidate `Vec`.
     
     The bug is reachable by any caller of `DnssecDnsHandle` — including the
     resolver, recursor, and client — when built with the `dnssec-ring` or
     `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is
     triggered while validating a NoData or NXDomain response whose authority
     section contains an SOA record from a zone other than an ancestor of the
     QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice
     this can be reached through an insecure CNAME chain that crosses zone
     boundaries into a DNSSEC-signed zone returning NoData, but the minimum
     condition is just a mismatched SOA owner on a response requiring NSEC3
     validation.
     
     A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds
     abort with a panic on the first iteration past the root. Release builds
     compile the assertion out and run the loop unbounded, allocating until the
     process exhausts available memory (OOM). A reachable upstream attacker who
     can return such a response can therefore crash a debug-built validator or
     exhaust memory on a release-built one.
     
     The affected code was migrated from `hickory-proto` to `hickory-net` as part of
     the 0.26.0 release. The `hickory-proto` 0.26.x release no longer offers
     `DnssecDnsHandle` and so we recommend all affected users update to `hickory-net`
     0.26.1 when the implementation of that type is required.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465
   ├ Solution: No safe upgrade is available!
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-common v5.2.0

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:65:1
   │
65 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0119
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0119
   ├ During message encoding, `hickory-proto`'s `BinEncoder` stores pointers to
     labels that are candidates for name compression in a `Vec<(usize, Vec<u8>)>`.
     The name compression logic then searches for matches with a linear scan.
     
     A malicious message with many records can both introduce many candidate labels,
     and invoke this linear scan many times. This can amplify CPU exhaustion in DoS
     attacks.
     
     This is similar to
     [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).
     
     We recommend all affected users update to `hickory-proto` 0.26.1 for the fix.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp
   ├ Solution: Upgrade to >=0.26.1 (try `cargo update -p hickory-proto`)
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-common v5.2.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:131:1
    │
131 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── libdd-common v5.2.0
      └── proptest v1.5.0
          └── (dev) libdd-common v5.2.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-data-pipeline-core - 3 error(s)

Show output
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:63:1
   │
63 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v5.2.0
                     │   ├── libdd-capabilities-impl v4.0.0
                     │   │   └── libdd-trace-utils v10.1.0
                     │   │       ├── libdd-data-pipeline-core v1.0.0
                     │   │       └── (dev) libdd-trace-utils v10.1.0 (*)
                     │   ├── libdd-data-pipeline-core v1.0.0 (*)
                     │   └── libdd-trace-utils v10.1.0 (*)
                     ├── (dev) libdd-trace-normalization v3.0.1
                     │   └── libdd-trace-utils v10.1.0 (*)
                     └── (dev) libdd-trace-utils v10.1.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:97:1
   │
97 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0258
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
   ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
     If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
     
     Low severity.
     
     Patched in v0.4.16.
   ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
   ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
   ├ h2 v0.4.6
     └── hyper v1.6.0
         ├── httpmock v0.8.0-alpha.1
         │   └── libdd-trace-utils v10.1.0
         │       ├── libdd-data-pipeline-core v1.0.0
         │       └── (dev) libdd-trace-utils v10.1.0 (*)
         ├── hyper-rustls v0.27.7
         │   └── libdd-common v5.2.0
         │       ├── libdd-capabilities-impl v4.0.0
         │       │   └── libdd-trace-utils v10.1.0 (*)
         │       ├── libdd-data-pipeline-core v1.0.0 (*)
         │       └── libdd-trace-utils v10.1.0 (*)
         ├── hyper-util v0.1.17
         │   ├── httpmock v0.8.0-alpha.1 (*)
         │   ├── hyper-rustls v0.27.7 (*)
         │   └── libdd-common v5.2.0 (*)
         ├── libdd-common v5.2.0 (*)
         └── libdd-trace-utils v10.1.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:187:1
    │
187 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── (dev) libdd-common v5.2.0
      │   ├── libdd-capabilities-impl v4.0.0
      │   │   └── libdd-trace-utils v10.1.0
      │   │       ├── libdd-data-pipeline-core v1.0.0
      │   │       └── (dev) libdd-trace-utils v10.1.0 (*)
      │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   └── libdd-trace-utils v10.1.0 (*)
      ├── (dev) libdd-trace-normalization v3.0.1
      │   └── libdd-trace-utils v10.1.0 (*)
      ├── libdd-trace-utils v10.1.0 (*)
      └── proptest v1.5.0
          ├── (dev) libdd-common v5.2.0 (*)
          └── (dev) libdd-tinybytes v1.1.2
              ├── (dev) libdd-data-pipeline-core v1.0.0 (*)
              ├── (dev) libdd-tinybytes v1.1.2 (*)
              └── libdd-trace-utils v10.1.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-data-pipeline - 4 error(s)

Show output
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:77:1
   │
77 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v5.2.0
                     │   ├── libdd-capabilities-impl v4.0.0
                     │   │   ├── libdd-data-pipeline v8.0.0
                     │   │   ├── libdd-shared-runtime v3.0.0
                     │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   │   │   ├── libdd-dogstatsd-client v5.0.0
                     │   │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v7.0.0
                     │   │   │   │       └── libdd-data-pipeline v8.0.0 (*)
                     │   │   │   ├── libdd-telemetry v7.0.0
                     │   │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v7.0.0 (*)
                     │   │   │   └── libdd-trace-stats v7.0.0 (*)
                     │   │   ├── (dev) libdd-telemetry v7.0.0 (*)
                     │   │   ├── libdd-trace-stats v7.0.0 (*)
                     │   │   └── libdd-trace-utils v10.1.0
                     │   │       ├── libdd-data-pipeline v8.0.0 (*)
                     │   │       ├── libdd-data-pipeline-core v1.0.0
                     │   │       │   └── libdd-data-pipeline v8.0.0 (*)
                     │   │       ├── libdd-trace-obfuscation v6.0.0
                     │   │       │   └── libdd-trace-stats v7.0.0 (*)
                     │   │       ├── libdd-trace-stats v7.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v10.1.0 (*)
                     │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   ├── libdd-data-pipeline-core v1.0.0 (*)
                     │   ├── libdd-dogstatsd-client v5.0.0 (*)
                     │   ├── libdd-shared-runtime v3.0.0 (*)
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   ├── libdd-trace-obfuscation v6.0.0 (*)
                     │   ├── libdd-trace-stats v7.0.0 (*)
                     │   └── libdd-trace-utils v10.1.0 (*)
                     ├── (dev) libdd-data-pipeline v8.0.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.1
                     │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   └── libdd-trace-stats v7.0.0 (*)
                     ├── (dev) libdd-trace-normalization v3.0.1
                     │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   └── libdd-trace-utils v10.1.0 (*)
                     ├── (dev) libdd-trace-obfuscation v6.0.0 (*)
                     ├── (dev) libdd-trace-stats v7.0.0 (*)
                     └── (dev) libdd-trace-utils v10.1.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:117:1
    │
117 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0258
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
    ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
      If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
      
      Low severity.
      
      Patched in v0.4.16.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
    ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
    ├ h2 v0.4.6
      └── hyper v1.6.0
          ├── httpmock v0.8.0-alpha.1
          │   ├── (dev) libdd-data-pipeline v8.0.0
          │   ├── (dev) libdd-telemetry v7.0.0
          │   │   ├── libdd-data-pipeline v8.0.0 (*)
          │   │   └── libdd-trace-stats v7.0.0
          │   │       └── libdd-data-pipeline v8.0.0 (*)
          │   ├── (dev) libdd-trace-stats v7.0.0 (*)
          │   └── libdd-trace-utils v10.1.0
          │       ├── libdd-data-pipeline v8.0.0 (*)
          │       ├── libdd-data-pipeline-core v1.0.0
          │       │   └── libdd-data-pipeline v8.0.0 (*)
          │       ├── libdd-trace-obfuscation v6.0.0
          │       │   └── libdd-trace-stats v7.0.0 (*)
          │       ├── libdd-trace-stats v7.0.0 (*)
          │       └── (dev) libdd-trace-utils v10.1.0 (*)
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v5.2.0
          │       ├── libdd-capabilities-impl v4.0.0
          │       │   ├── libdd-data-pipeline v8.0.0 (*)
          │       │   ├── libdd-shared-runtime v3.0.0
          │       │   │   ├── libdd-data-pipeline v8.0.0 (*)
          │       │   │   ├── libdd-dogstatsd-client v5.0.0
          │       │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
          │       │   │   │   └── libdd-trace-stats v7.0.0 (*)
          │       │   │   ├── libdd-telemetry v7.0.0 (*)
          │       │   │   └── libdd-trace-stats v7.0.0 (*)
          │       │   ├── (dev) libdd-telemetry v7.0.0 (*)
          │       │   ├── libdd-trace-stats v7.0.0 (*)
          │       │   └── libdd-trace-utils v10.1.0 (*)
          │       ├── libdd-data-pipeline v8.0.0 (*)
          │       ├── libdd-data-pipeline-core v1.0.0 (*)
          │       ├── libdd-dogstatsd-client v5.0.0 (*)
          │       ├── libdd-shared-runtime v3.0.0 (*)
          │       ├── libdd-telemetry v7.0.0 (*)
          │       ├── libdd-trace-obfuscation v6.0.0 (*)
          │       ├── libdd-trace-stats v7.0.0 (*)
          │       └── libdd-trace-utils v10.1.0 (*)
          ├── hyper-util v0.1.17
          │   ├── httpmock v0.8.0-alpha.1 (*)
          │   ├── hyper-rustls v0.27.7 (*)
          │   └── libdd-common v5.2.0 (*)
          ├── libdd-common v5.2.0 (*)
          └── libdd-trace-utils v10.1.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:224:1
    │
224 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── libdd-common v5.2.0
      │   ├── libdd-capabilities-impl v4.0.0
      │   │   ├── libdd-data-pipeline v8.0.0
      │   │   ├── libdd-shared-runtime v3.0.0
      │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
      │   │   │   ├── libdd-dogstatsd-client v5.0.0
      │   │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v7.0.0
      │   │   │   │       └── libdd-data-pipeline v8.0.0 (*)
      │   │   │   ├── libdd-telemetry v7.0.0
      │   │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v7.0.0 (*)
      │   │   │   └── libdd-trace-stats v7.0.0 (*)
      │   │   ├── (dev) libdd-telemetry v7.0.0 (*)
      │   │   ├── libdd-trace-stats v7.0.0 (*)
      │   │   └── libdd-trace-utils v10.1.0
      │   │       ├── libdd-data-pipeline v8.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v1.0.0
      │   │       │   └── libdd-data-pipeline v8.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v6.0.0
      │   │       │   └── libdd-trace-stats v7.0.0 (*)
      │   │       ├── libdd-trace-stats v7.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v10.1.0 (*)
      │   ├── libdd-data-pipeline v8.0.0 (*)
      │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   ├── libdd-dogstatsd-client v5.0.0 (*)
      │   ├── libdd-shared-runtime v3.0.0 (*)
      │   ├── libdd-telemetry v7.0.0 (*)
      │   ├── libdd-trace-obfuscation v6.0.0 (*)
      │   ├── libdd-trace-stats v7.0.0 (*)
      │   └── libdd-trace-utils v10.1.0 (*)
      ├── (dev) libdd-data-pipeline v8.0.0 (*)
      ├── (dev) libdd-ddsketch v1.1.1
      │   ├── libdd-data-pipeline v8.0.0 (*)
      │   ├── libdd-telemetry v7.0.0 (*)
      │   └── libdd-trace-stats v7.0.0 (*)
      ├── (dev) libdd-trace-normalization v3.0.1
      │   ├── libdd-data-pipeline v8.0.0 (*)
      │   └── libdd-trace-utils v10.1.0 (*)
      ├── (dev) libdd-trace-stats v7.0.0 (*)
      ├── libdd-trace-utils v10.1.0 (*)
      └── proptest v1.5.0
          ├── (dev) libdd-common v5.2.0 (*)
          └── (dev) libdd-tinybytes v1.1.2
              ├── libdd-data-pipeline v8.0.0 (*)
              ├── (dev) libdd-data-pipeline-core v1.0.0 (*)
              ├── (dev) libdd-tinybytes v1.1.2 (*)
              └── libdd-trace-utils v10.1.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:296:1
    │
296 │ time 0.3.41 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0009
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
    ├ ## Impact
      
      When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
      service attack via stack exhaustion is possible. The attack relies on formally deprecated and
      rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
      non-malicious input will never encounter this scenario.
      
      ## Patches
      
      A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
      rather than exhausting the stack.
      
      ## Workarounds
      
      Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
      the stack consumed would be at most a factor of the length of the input.
    ├ Announcement: https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05
    ├ Solution: Upgrade to >=0.3.47 (try `cargo update -p time`)
    ├ time v0.3.41
      └── tracing-appender v0.2.3
          └── libdd-log v1.0.0
              └── (dev) libdd-data-pipeline v8.0.0

advisories FAILED, bans ok, sources ok

📦 libdd-http-client - 4 error(s)

Show output
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:36:1
   │
36 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── moka v0.12.13
         └── hickory-resolver v0.25.2
             └── reqwest v0.13.2
                 └── libdd-http-client v1.0.0

error[vulnerability]: h2 unbounded empty DATA frames
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:65:1
   │
65 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0258
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
   ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
     If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
     
     Low severity.
     
     Patched in v0.4.16.
   ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
   ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
   ├ h2 v0.4.6
     └── hyper v1.6.0
         ├── httpmock v0.8.0-alpha.1
         │   └── (dev) libdd-http-client v1.0.0
         ├── hyper-rustls v0.27.7
         │   └── reqwest v0.13.2
         │       └── libdd-http-client v1.0.0 (*)
         ├── hyper-util v0.1.17
         │   ├── httpmock v0.8.0-alpha.1 (*)
         │   ├── hyper-rustls v0.27.7 (*)
         │   └── reqwest v0.13.2 (*)
         └── reqwest v0.13.2 (*)

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:72:1
   │
72 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0118
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0118
   ├ The NSEC3 closest-encloser proof validation in `hickory-proto`'s
     `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a
     list of candidate encloser names. The iterator used assumes the
     QNAME is a descendant of the SOA owner, terminating only when the current
     candidate equals the SOA name. When the SOA in a response's authority section
     is not an ancestor of the QNAME, the loop stalls at the DNS root and never
     terminates, repeatedly calling `Name::base_name()` and pushing newly allocated
     `Name` and hashed-name entries into the candidate `Vec`.
     
     The bug is reachable by any caller of `DnssecDnsHandle` — including the
     resolver, recursor, and client — when built with the `dnssec-ring` or
     `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is
     triggered while validating a NoData or NXDomain response whose authority
     section contains an SOA record from a zone other than an ancestor of the
     QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice
     this can be reached through an insecure CNAME chain that crosses zone
     boundaries into a DNSSEC-signed zone returning NoData, but the minimum
     condition is just a mismatched SOA owner on a response requiring NSEC3
     validation.
     
     A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds
     abort with a panic on the first iteration past the root. Release builds
     compile the assertion out and run the loop unbounded, allocating until the
     process exhausts available memory (OOM). A reachable upstream attacker who
     can return such a response can therefore crash a debug-built validator or
     exhaust memory on a release-built one.
     
     The affected code was migrated from `hickory-proto` to `hickory-net` as part of
     the 0.26.0 release. The `hickory-proto` 0.26.x release no longer offers
     `DnssecDnsHandle` and so we recommend all affected users update to `hickory-net`
     0.26.1 when the implementation of that type is required.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465
   ├ Solution: No safe upgrade is available!
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-http-client v1.0.0

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:72:1
   │
72 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0119
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0119
   ├ During message encoding, `hickory-proto`'s `BinEncoder` stores pointers to
     labels that are candidates for name compression in a `Vec<(usize, Vec<u8>)>`.
     The name compression logic then searches for matches with a linear scan.
     
     A malicious message with many records can both introduce many candidate labels,
     and invoke this linear scan many times. This can amplify CPU exhaustion in DoS
     attacks.
     
     This is similar to
     [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).
     
     We recommend all affected users update to `hickory-proto` 0.26.1 for the fix.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp
   ├ Solution: Upgrade to >=0.26.1 (try `cargo update -p hickory-proto`)
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-http-client v1.0.0

advisories FAILED, bans ok, sources ok

📦 libdd-trace-utils - 3 error(s)

Show output
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:63:1
   │
63 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v5.2.0
                     │   ├── libdd-capabilities-impl v4.0.0
                     │   │   └── libdd-trace-utils v10.1.0
                     │   │       └── (dev) libdd-trace-utils v10.1.0 (*)
                     │   └── libdd-trace-utils v10.1.0 (*)
                     ├── (dev) libdd-trace-normalization v3.0.1
                     │   └── libdd-trace-utils v10.1.0 (*)
                     └── (dev) libdd-trace-utils v10.1.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:97:1
   │
97 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0258
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
   ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
     If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
     
     Low severity.
     
     Patched in v0.4.16.
   ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
   ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
   ├ h2 v0.4.6
     └── hyper v1.6.0
         ├── httpmock v0.8.0-alpha.1
         │   └── libdd-trace-utils v10.1.0
         │       └── (dev) libdd-trace-utils v10.1.0 (*)
         ├── hyper-rustls v0.27.7
         │   └── libdd-common v5.2.0
         │       ├── libdd-capabilities-impl v4.0.0
         │       │   └── libdd-trace-utils v10.1.0 (*)
         │       └── libdd-trace-utils v10.1.0 (*)
         ├── hyper-util v0.1.17
         │   ├── httpmock v0.8.0-alpha.1 (*)
         │   ├── hyper-rustls v0.27.7 (*)
         │   └── libdd-common v5.2.0 (*)
         ├── libdd-common v5.2.0 (*)
         └── libdd-trace-utils v10.1.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:184:1
    │
184 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── (dev) libdd-common v5.2.0
      │   ├── libdd-capabilities-impl v4.0.0
      │   │   └── libdd-trace-utils v10.1.0
      │   │       └── (dev) libdd-trace-utils v10.1.0 (*)
      │   └── libdd-trace-utils v10.1.0 (*)
      ├── (dev) libdd-trace-normalization v3.0.1
      │   └── libdd-trace-utils v10.1.0 (*)
      ├── libdd-trace-utils v10.1.0 (*)
      └── proptest v1.5.0
          ├── (dev) libdd-common v5.2.0 (*)
          └── (dev) libdd-tinybytes v1.1.2
              ├── (dev) libdd-tinybytes v1.1.2 (*)
              └── libdd-trace-utils v10.1.0 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-08-26 03:49:55 UTC | Commit: 991cd22 | dependency-check job results

@dd-octo-sts

dd-octo-sts Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

Artifact Size Benchmark Report

aarch64-alpine-linux-musl
Artifact Baseline Commit Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 8.26 MB 8.26 MB -0% (-24 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 89.52 MB 89.54 MB +.02% (+22.82 KB) 🔍
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 100.70 MB 100.71 MB +0% (+7.54 KB) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.06 MB 11.06 MB +0% (+880 B) 👌
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 26.64 MB 26.64 MB 0% (0 B) 👌
/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 180.73 MB 180.86 MB +.07% (+136.00 KB) 🔍
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 772.85 MB 772.66 MB --.02% (-199.00 KB) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 8.73 MB 8.73 MB +.02% (+2.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.65 MB 25.66 MB +.06% (+16.00 KB) 🔍
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 51.09 MB 51.10 MB +.02% (+13.41 KB) 🔍
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 23.22 MB 23.22 MB -0% (-1.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 185.66 MB 185.80 MB +.07% (+144.00 KB) 🔍
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 759.09 MB 760.92 MB +.24% (+1.83 MB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 6.74 MB 6.75 MB +.03% (+2.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.59 MB 27.60 MB +.02% (+8.00 KB) 🔍
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 48.62 MB 48.65 MB +.04% (+23.82 KB) 🔍
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 79.78 MB 79.81 MB +.03% (+24.65 KB) 🔍
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 9.16 MB 9.16 MB -0% (-32 B) 👌
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 95.42 MB 95.46 MB +.03% (+32.01 KB) 🔍
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.17 MB 11.17 MB +.01% (+1.62 KB) 🔍

@pr-commenter

pr-commenter Bot commented Aug 21, 2026

Copy link
Copy Markdown

Benchmarks

Comparison

Benchmark execution time: 2026-08-26 04:22:48

Comparing candidate commit cbe142c in PR branch rochdev/host-managed-data-pipeline with baseline commit 7d13807 in branch main.

Found 6 performance improvements and 10 performance regressions! Performance is the same for 136 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:otlp/e2e_json/1x1000

  • 🟥 execution_time [+398.719µs; +400.561µs] or [+9.632%; +9.677%]

scenario:otlp/encode_json/1x1000

  • 🟥 execution_time [+380.181µs; +380.719µs] or [+20.993%; +21.022%]

scenario:otlp/encode_protobuf/1x1000

  • 🟩 execution_time [-49.380µs; -48.629µs] or [-4.433%; -4.366%]

scenario:sdk_test_data/rules-based

  • 🟩 execution_time [-122.080µs; -118.326µs] or [-45.961%; -44.547%]

scenario:vec_map/contains_key/8

  • 🟥 execution_time [+3.345ns; +3.484ns] or [+4.481%; +4.667%]
  • 🟥 throughput [-4781592.088op/s; -4593658.664op/s] or [-4.462%; -4.286%]

scenario:vec_map/get_hit/16

  • 🟩 execution_time [-49.163ns; -48.958ns] or [-19.680%; -19.598%]
  • 🟩 throughput [+15620763.371op/s; +15684644.238op/s] or [+24.389%; +24.488%]

scenario:vec_map/get_hit/8

  • 🟩 execution_time [-10.593ns; -10.515ns] or [-16.335%; -16.214%]
  • 🟩 throughput [+23894809.010op/s; +24062704.936op/s] or [+19.369%; +19.505%]

scenario:vec_map/iter/128

  • 🟥 execution_time [+7.540ns; +7.743ns] or [+7.236%; +7.432%]
  • 🟥 throughput [-85074387.289op/s; -82873354.087op/s] or [-6.925%; -6.746%]

scenario:vec_map/iter/16

  • 🟥 execution_time [+0.556ns; +0.574ns] or [+4.236%; +4.373%]
  • 🟥 throughput [-51140740.919op/s; -49552589.417op/s] or [-4.194%; -4.063%]

scenario:vec_map/iter/8

  • 🟥 execution_time [+0.537ns; +0.550ns] or [+8.020%; +8.200%]
  • 🟥 throughput [-90618330.642op/s; -88572811.917op/s] or [-7.591%; -7.419%]

Benchmark execution time: 2026-08-26 04:31:42

Comparing candidate commit cbe142c in PR branch rochdev/host-managed-data-pipeline with baseline commit 7d13807 in branch main.

Found 13 performance improvements and 12 performance regressions! Performance is the same for 143 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 [+11.155ns; +11.323ns] or [+13.932%; +14.141%]

scenario:credit_card/is_card_number/ 378282246310005

  • 🟥 execution_time [+8.088µs; +8.219µs] or [+11.020%; +11.198%]
  • 🟥 throughput [-1374334.064op/s; -1351126.992op/s] or [-10.087%; -9.916%]

scenario:credit_card/is_card_number/378282246310005

  • 🟩 execution_time [-17.212µs; -17.094µs] or [-20.894%; -20.751%]
  • 🟩 throughput [+3183397.843op/s; +3200999.101op/s] or [+26.223%; +26.368%]

scenario:credit_card/is_card_number/37828224631000521389798

  • 🟩 execution_time [-6.534µs; -6.469µs] or [-12.486%; -12.361%]
  • 🟩 throughput [+2696094.191op/s; +2726789.293op/s] or [+14.108%; +14.269%]

scenario:credit_card/is_card_number/x371413321323331

  • 🟥 execution_time [+596.762ns; +600.685ns] or [+9.865%; +9.929%]
  • 🟥 throughput [-14932309.131op/s; -14839831.262op/s] or [-9.033%; -8.977%]

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

  • 🟩 execution_time [-5.422µs; -5.379µs] or [-9.200%; -9.126%]
  • 🟩 throughput [+1705019.997op/s; +1717838.097op/s] or [+10.049%; +10.124%]

scenario:credit_card/is_card_number_no_luhn/378282246310005

  • 🟩 execution_time [-5.266µs; -5.233µs] or [-9.478%; -9.418%]
  • 🟩 throughput [+1871956.487op/s; +1883231.003op/s] or [+10.402%; +10.465%]

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

  • 🟩 execution_time [-6.431µs; -6.379µs] or [-12.289%; -12.188%]
  • 🟩 throughput [+2652610.427op/s; +2677201.145op/s] or [+13.882%; +14.011%]

scenario:credit_card/is_card_number_no_luhn/x371413321323331

  • 🟥 execution_time [+598.796ns; +602.093ns] or [+9.901%; +9.956%]
  • 🟥 throughput [-14972453.849op/s; -14894319.324op/s] or [-9.055%; -9.008%]

scenario:datadog_sample_span/parent_not_sampled_short_circuit/wall_time

  • 🟩 execution_time [-0.406ns; -0.399ns] or [-4.382%; -4.311%]

scenario:datadog_sample_span/parent_sampled_short_circuit/wall_time

  • 🟩 execution_time [-0.404ns; -0.399ns] or [-4.360%; -4.307%]

scenario:glob_matcher/ascii_case_insensitive_match/wall_time

  • 🟥 execution_time [+1.549ns; +1.578ns] or [+5.804%; +5.912%]

scenario:glob_matcher/ascii_exact_match/wall_time

  • 🟥 execution_time [+1.530ns; +1.545ns] or [+5.733%; +5.789%]

scenario:glob_matcher/ascii_exact_miss/wall_time

  • 🟥 execution_time [+2.043ns; +2.071ns] or [+17.445%; +17.685%]

scenario:profiler_attached/fast_path_system/4096

  • 🟩 execution_time [-13.056ns; -12.903ns] or [-11.095%; -10.965%]

scenario:trace_buffer/2_senders/no_delay

  • 🟥 execution_time [+144.599µs; +160.053µs] or [+9.168%; +10.148%]
  • 🟥 throughput [-105818.126op/s; -95555.970op/s] or [-9.266%; -8.368%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

@rochdev
rochdev marked this pull request as ready for review August 21, 2026 14:01
@rochdev
rochdev requested review from a team as code owners August 21, 2026 14:01

@chatgpt-codex-connector chatgpt-codex-connector Bot 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.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: fc9ff139a3

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread libdd-data-pipeline-core/src/agentless.rs Outdated
Comment thread libdd-data-pipeline-core/src/agentless.rs Outdated
Comment thread libdd-data-pipeline-core/src/agentless.rs Outdated
Comment thread libdd-common/src/lib.rs
@rochdev
rochdev force-pushed the rochdev/host-managed-data-pipeline branch from fc9ff13 to 1c04286 Compare August 21, 2026 15:39
@rochdev
rochdev force-pushed the rochdev/host-managed-data-pipeline branch from 1c04286 to 52dfcbb Compare August 21, 2026 17:26
bengl
bengl previously approved these changes Aug 21, 2026

@bengl bengl left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Seems fine to me, but @DataDog/apm-common-components-core should probably review.

@rochdev
rochdev dismissed bengl’s stale review August 23, 2026 03:03

Implementation changed significantly to keep retries on the Rust side.

@rochdev

rochdev commented Aug 24, 2026

Copy link
Copy Markdown
Member Author

@codex review

@chatgpt-codex-connector chatgpt-codex-connector Bot 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.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 322d9336fe

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread libdd-common/src/lib.rs

@paullegranddc paullegranddc left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Overall, I'd like to push back against this pull request.
First without the matching libdatadog-nodejs PR it is very hard to reason about which APIs are necessary and which are not.

But more than this, I don't understand why we need the PreparedRequest level of abstraction, and this is not really motivated in the PR description.

What is the goal here

  1. Is it getting just a bag of data with the request and then doing the http request fully in NodeJS?
  2. Or is it to have a send_agentless function that takes messagepack &[u8] serialized trace chunk and uses the existing capabilities implementation to drive calling to the node http stack from rust?

While I am not completely against 1), I would much prefer option 2) as it doesn't expose as much details of libdatadog to nodeJS and you should just be able to hook the exisitng WASM capabilities implementation.

We should just do something like

NodeJS                      |   Rust                                               | NodeJS
send(chunk) -> encode msp   -> send(traces: &[u8]) -> encode() -> send_with_retry ->  http capability impl

and not

NodeJS                        |   Rust                                              | NodeJS                         | Rust             | NodeJS           
prepare(chunk) -> encode msp  -> prepare(traces: &[u8]) -> returns prepared request -> send_rust(prepared_request)   -> send_with_retry ->  http capability 

payload: Bytes,
headers: HeaderMap,
compression_strategy: CompressionStrategy,
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

How is this different from an http::Request<Bytes> ?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Just a small abstraction but it should be effectively equivalent, let me see if I can simplify.

Comment thread libdd-common/Cargo.toml
pin-project = "1"
libc.workspace = true
tokio = { workspace = true, features = ["rt", "rt-multi-thread", "macros", "net", "io-util", "fs", "time"] }
tokio = { workspace = true, features = ["rt", "rt-multi-thread", "macros", "net", "io-util", "fs", "time"], optional = true }

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Why are these marked as optional. The are already not added for wasm and the codepaths providing the http client are already gated as to compile the crate.

So I don't see how refactoring libdd-common in necessary

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

WASM is only half the equation. Without making them explicitly optional, NAPI-RS was still including them. While some things are build target specific, some other things are not and need to be controllable regardless of the target.

Comment on lines +113 to +118
if jitter_ms == 0 {
delay
} else {
let randomized_ms = rand::random::<u64>() % jitter_ms;
delay.saturating_add(Duration::from_millis(randomized_ms))
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

This branch here is kind of useless. It is equivalent if the jitter_ms == 0 branch is removed and we gain just a call to random in a case that basically never happens

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I'll try to clean this up.

Comment on lines +104 to +109
/// Converts v0.4 MessagePack traces into a host-transported request.
pub fn prepare_agentless_v04_request(
data: &[u8],
metadata: &TracerMetadata,
config: &AgentlessTraceConfig,
) -> Result<PreparedAgentlessRequest, PrepareAgentlessError> {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

This is very specific to the way you want to integrate libdatadog in NodeJS, so I would prefer if this function lived in libdatadog-nodejs rather than here.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Let me try to see if this can be removed.

compression::add_headers(h, compression_strategy);
}
let req = match builder.body(payload.clone()) {
let req = match prepared.request() {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

This is not good.
Calling to .request() will do compression on the body but this is inside of the retry loop.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

PreparedRequest handles this so it's not an issue with the current implementation, but I'll try to see if we can remove PrepareRequest completely since half the comments are about it.

@rochdev rochdev changed the title feat(data-pipeline): add runtime-independent request preparation feat(data-pipeline): add runtime-independent agentless sending Aug 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants