chore!: remove unused dependencies (v2) by Eldolfin · Pull Request #2511 · DataDog/libdatadog

Eldolfin · 2026-09-11T12:23:23Z

What does this PR do?

Removes unused dependencies across the workspace.

This is a v2 of #2319. I ran cargo machete with metadata, then audited every finding to preserve false positives required by build scripts, targets, features, and workspace resolution.

Motivation

Hopefully slightly faster compile times and a simpler dependency tree
Cleaner repo overall

Additional Notes

The cargo-machete allow list will be added in a follow-up.

In libdd-common/Cargo.toml, I'm not sure the removal of tokio-rustls and rustls-native-certs is good. However it didn't seem to have broken tests

How to test the change?

CI should be able to catch if I broke something.

APMSP-3056

[Generated using codex]

github-actions · 2026-09-11T12:27:15Z

🔒 Cargo Deny Results

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

📦 `bin_tests` - ✅ No issues

📦 `build_common` - ✅ No issues

📦 `datadog-sidecar-ffi` - 3 error(s)

Show output

error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:35:1
   │
35 │ bincode 1.3.3 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2025-0141
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0141
   ├ Due to a doxxing and harassment incident, the bincode team has taken the decision to cease development permanently.
     
     The team considers version 1.3.3 a complete version of bincode that is not in need of any updates.
     
     ## Alternatives to consider
     
     * [wincode](https://crates.io/crates/wincode)
     * [postcard](https://crates.io/crates/postcard)
     * [bitcode](https://crates.io/crates/bitcode)
     * [rkyv](https://crates.io/crates/rkyv)
   ├ Announcement: https://git.sr.ht/~stygianentity/bincode/tree/v3.0/item/README.md
   ├ Solution: No safe upgrade is available!
   ├ bincode v1.3.3
     ├── datadog-sidecar v0.0.1
     │   └── datadog-sidecar-ffi v0.0.1
     ├── (dev) libdd-ffe v2.0.0
     │   └── datadog-sidecar v0.0.1 (*)
     └── libdd-ipc v2.0.0
         ├── datadog-sidecar v0.0.1 (*)
         └── datadog-sidecar-ffi v0.0.1 (*)

error[unsound]: Potential use-after-free due to lack of panic safety in `LruCache::pop()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:232:1
    │
232 │ lru 0.16.4 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0253
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0253
    ├ `LruCache::pop()` in `lru` was not panic-safe. If the `Drop` implementation of a stored key panics during `pop()`, `self.detach()` is never called, leaving dangling pointers in the internal doubly-linked list.
      
      A subsequent cache operation that triggers eviction can then dereference these dangling pointers:
      - The node is freed from the map, but remains linked in the LRU list due to the skipped `detach()` call
      - When a new insertion causes eviction, the LRU traversal encounters the dangling pointer
      - This results in a write to already-freed memory during the eviction process
      
      ## Impact
      
      - **CWE-416 (Use-After-Free):** memory corruption when subsequent cache operations access freed node pointers in the linked list
      - **CWE-415 (Double Free):** potential heap corruption when the same memory is freed multiple times
      
      Both types of undefined behavior can be invoked in safe Rust, but only if unwinding panics are enabled and `std::panic::catch_unwind` is used with key types that have potentially-panicking `Drop` implementations.
      
      ## Fix
      
      Fixed in `lru` 0.18.2 by detaching the node from the linked list before freeing it and dropping the key ([lru-rs#238](https://github.com/jeromefroe/lru-rs/pull/238)).
    ├ Announcement: https://github.com/jeromefroe/lru-rs/pull/238
    ├ Solution: Upgrade to >=0.18.2 (try `cargo update -p lru`)
    ├ lru v0.16.4
      └── libdd-ffe v2.0.0
          └── datadog-sidecar v0.0.1
              └── datadog-sidecar-ffi v0.0.1

error[unmaintained]: paste - no longer maintained
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:273:1
    │
273 │ paste 1.0.15 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
    │
    ├ ID: RUSTSEC-2024-0436
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0436
    ├ The creator of the crate `paste` has stated in the [`README.md`](https://github.com/dtolnay/paste/blob/master/README.md) 
      that this project is not longer maintained as well as archived the repository
      
      ## Possible Alternative(s)
      
      - [`pastey`]: a fork of paste and is aimed to be a drop-in replacement with additional features for paste crate
      - [`with_builtin_macros`]: crate providing a [superset of `paste`'s functionality including general `macro_rules!` eager expansions](https://docs.rs/with_builtin_macros/0.1.0/with_builtin_macros/macro.with_eager_expansions.html)  and `concat!`/`concat_idents!` macros
      
      [`pastey`]: https://crates.io/crates/pastey
      [`with_builtin_macros`]: https://crates.io/crates/with_builtin_macros
    ├ Announcement: https://github.com/dtolnay/paste
    ├ Solution: No safe upgrade is available!
    ├ paste v1.0.15
      ├── libdd-libunwind-sys v1.0.3
      │   └── libdd-crashtracker v3.0.0
      │       ├── datadog-sidecar v0.0.1
      │       │   └── datadog-sidecar-ffi v0.0.1
      │       ├── datadog-sidecar-ffi v0.0.1 (*)
      │       └── libdd-crashtracker-ffi v44.0.0
      │           ├── datadog-sidecar v0.0.1 (*)
      │           └── datadog-sidecar-ffi v0.0.1 (*)
      ├── libdd-telemetry-ffi v44.0.0
      │   └── datadog-sidecar-ffi v0.0.1 (*)
      └── rmp v0.8.14
          ├── libdd-trace-utils v12.0.0
          │   ├── (dev) datadog-sidecar v0.0.1 (*)
          │   ├── (dev) datadog-sidecar-ffi v0.0.1 (*)
          │   ├── libdd-data-pipeline v10.0.0
          │   │   ├── datadog-sidecar v0.0.1 (*)
          │   │   └── libdd-live-debugger v1.0.0
          │   │       ├── datadog-sidecar v0.0.1 (*)
          │   │       └── datadog-sidecar-ffi v0.0.1 (*)
          │   ├── libdd-data-pipeline-core v1.0.0
          │   │   └── libdd-data-pipeline v10.0.0 (*)
          │   ├── libdd-trace-obfuscation v8.0.0
          │   │   ├── libdd-data-pipeline v10.0.0 (*)
          │   │   ├── libdd-data-pipeline-core v1.0.0 (*)
          │   │   └── libdd-trace-stats v9.0.0
          │   │       ├── datadog-sidecar v0.0.1 (*)
          │   │       ├── libdd-data-pipeline v10.0.0 (*)
          │   │       └── libdd-ipc v2.0.0
          │   │           ├── datadog-sidecar v0.0.1 (*)
          │   │           └── datadog-sidecar-ffi v0.0.1 (*)
          │   ├── libdd-trace-stats v9.0.0 (*)
          │   └── (dev) libdd-trace-utils v12.0.0 (*)
          ├── rmp-serde v1.3.0
          │   ├── datadog-sidecar-ffi v0.0.1 (*)
          │   ├── libdd-data-pipeline v10.0.0 (*)
          │   ├── (dev) libdd-tinybytes v1.1.3
          │   │   ├── datadog-sidecar v0.0.1 (*)
          │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
          │   │   ├── libdd-data-pipeline v10.0.0 (*)
          │   │   ├── (dev) libdd-data-pipeline-core v1.0.0 (*)
          │   │   ├── libdd-ipc v2.0.0 (*)
          │   │   ├── (dev) libdd-tinybytes v1.1.3 (*)
          │   │   ├── (dev) libdd-trace-obfuscation v8.0.0 (*)
          │   │   └── libdd-trace-utils v12.0.0 (*)
          │   ├── libdd-trace-stats v9.0.0 (*)
          │   └── libdd-trace-utils v12.0.0 (*)
          └── rmpv v1.3.0
              └── libdd-trace-utils v12.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 `datadog-sidecar` - 2 error(s)

Show output

error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:35:1
   │
35 │ bincode 1.3.3 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2025-0141
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0141
   ├ Due to a doxxing and harassment incident, the bincode team has taken the decision to cease development permanently.
     
     The team considers version 1.3.3 a complete version of bincode that is not in need of any updates.
     
     ## Alternatives to consider
     
     * [wincode](https://crates.io/crates/wincode)
     * [postcard](https://crates.io/crates/postcard)
     * [bitcode](https://crates.io/crates/bitcode)
     * [rkyv](https://crates.io/crates/rkyv)
   ├ Announcement: https://git.sr.ht/~stygianentity/bincode/tree/v3.0/item/README.md
   ├ Solution: No safe upgrade is available!
   ├ bincode v1.3.3
     ├── datadog-sidecar v0.0.1
     ├── (dev) libdd-ffe v2.0.0
     │   └── datadog-sidecar v0.0.1 (*)
     └── libdd-ipc v2.0.0
         └── datadog-sidecar v0.0.1 (*)

error[unsound]: Potential use-after-free due to lack of panic safety in `LruCache::pop()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:230:1
    │
230 │ lru 0.16.4 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0253
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0253
    ├ `LruCache::pop()` in `lru` was not panic-safe. If the `Drop` implementation of a stored key panics during `pop()`, `self.detach()` is never called, leaving dangling pointers in the internal doubly-linked list.
      
      A subsequent cache operation that triggers eviction can then dereference these dangling pointers:
      - The node is freed from the map, but remains linked in the LRU list due to the skipped `detach()` call
      - When a new insertion causes eviction, the LRU traversal encounters the dangling pointer
      - This results in a write to already-freed memory during the eviction process
      
      ## Impact
      
      - **CWE-416 (Use-After-Free):** memory corruption when subsequent cache operations access freed node pointers in the linked list
      - **CWE-415 (Double Free):** potential heap corruption when the same memory is freed multiple times
      
      Both types of undefined behavior can be invoked in safe Rust, but only if unwinding panics are enabled and `std::panic::catch_unwind` is used with key types that have potentially-panicking `Drop` implementations.
      
      ## Fix
      
      Fixed in `lru` 0.18.2 by detaching the node from the linked list before freeing it and dropping the key ([lru-rs#238](https://github.com/jeromefroe/lru-rs/pull/238)).
    ├ Announcement: https://github.com/jeromefroe/lru-rs/pull/238
    ├ Solution: Upgrade to >=0.18.2 (try `cargo update -p lru`)
    ├ lru v0.16.4
      └── libdd-ffe v2.0.0
          └── datadog-sidecar v0.0.1

advisories FAILED, bans ok, sources ok

📦 `libdd-agent-client` - 2 error(s)

Show output

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:84:1
   │
84 │ 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 v2.0.0
                 └── libdd-agent-client v44.0.0

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:84:1
   │
84 │ 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 v2.0.0
                 └── libdd-agent-client v44.0.0

advisories FAILED, bans ok, sources ok

📦 `libdd-common` - 2 error(s)

Show output

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:66:1
   │
66 │ 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 v6.0.0

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:66:1
   │
66 │ 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 v6.0.0

advisories FAILED, bans ok, sources ok

📦 `libdd-crashtracker-ffi` - ✅ No issues

📦 `libdd-data-pipeline` - ✅ No issues

📦 `libdd-ffe` - 2 error(s)

Show output

error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:21:1
   │
21 │ bincode 1.3.3 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2025-0141
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0141
   ├ Due to a doxxing and harassment incident, the bincode team has taken the decision to cease development permanently.
     
     The team considers version 1.3.3 a complete version of bincode that is not in need of any updates.
     
     ## Alternatives to consider
     
     * [wincode](https://crates.io/crates/wincode)
     * [postcard](https://crates.io/crates/postcard)
     * [bitcode](https://crates.io/crates/bitcode)
     * [rkyv](https://crates.io/crates/rkyv)
   ├ Announcement: https://git.sr.ht/~stygianentity/bincode/tree/v3.0/item/README.md
   ├ Solution: No safe upgrade is available!
   ├ bincode v1.3.3
     └── (dev) libdd-ffe v2.0.0

error[unsound]: Potential use-after-free due to lack of panic safety in `LruCache::pop()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:127:1
    │
127 │ lru 0.16.4 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0253
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0253
    ├ `LruCache::pop()` in `lru` was not panic-safe. If the `Drop` implementation of a stored key panics during `pop()`, `self.detach()` is never called, leaving dangling pointers in the internal doubly-linked list.
      
      A subsequent cache operation that triggers eviction can then dereference these dangling pointers:
      - The node is freed from the map, but remains linked in the LRU list due to the skipped `detach()` call
      - When a new insertion causes eviction, the LRU traversal encounters the dangling pointer
      - This results in a write to already-freed memory during the eviction process
      
      ## Impact
      
      - **CWE-416 (Use-After-Free):** memory corruption when subsequent cache operations access freed node pointers in the linked list
      - **CWE-415 (Double Free):** potential heap corruption when the same memory is freed multiple times
      
      Both types of undefined behavior can be invoked in safe Rust, but only if unwinding panics are enabled and `std::panic::catch_unwind` is used with key types that have potentially-panicking `Drop` implementations.
      
      ## Fix
      
      Fixed in `lru` 0.18.2 by detaching the node from the linked list before freeing it and dropping the key ([lru-rs#238](https://github.com/jeromefroe/lru-rs/pull/238)).
    ├ Announcement: https://github.com/jeromefroe/lru-rs/pull/238
    ├ Solution: Upgrade to >=0.18.2 (try `cargo update -p lru`)
    ├ lru v0.16.4
      └── libdd-ffe v2.0.0

advisories FAILED, bans ok, sources ok

📦 `libdd-ipc` - 1 error(s)

Show output

error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:24:1
   │
24 │ bincode 1.3.3 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2025-0141
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0141
   ├ Due to a doxxing and harassment incident, the bincode team has taken the decision to cease development permanently.
     
     The team considers version 1.3.3 a complete version of bincode that is not in need of any updates.
     
     ## Alternatives to consider
     
     * [wincode](https://crates.io/crates/wincode)
     * [postcard](https://crates.io/crates/postcard)
     * [bitcode](https://crates.io/crates/bitcode)
     * [rkyv](https://crates.io/crates/rkyv)
   ├ Announcement: https://git.sr.ht/~stygianentity/bincode/tree/v3.0/item/README.md
   ├ Solution: No safe upgrade is available!
   ├ bincode v1.3.3
     └── libdd-ipc v2.0.0

advisories FAILED, bans ok, sources ok

📦 `libdd-library-config-ffi` - ✅ No issues

📦 `libdd-library-config` - ✅ No issues

📦 `libdd-live-debugger-ffi` - ✅ No issues

📦 `libdd-profiling-ffi` - 4 error(s)

Show output

error[unsound]: `Bitmap::try_from(&[u8])` can create invalid values
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:20:1
   │
20 │ bitmaps 3.2.1 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2025-0167
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0167
   ├ The `TryFrom<&[u8]>` implementation for `Bitmap<SIZE>` copies the input bytes
     into an uninitialized backing store and calls `assume_init()` without
     validating that the bytes form a valid value of the backing store type. For
     `SIZE = 1` the backing store is a `bool`, so any input byte other than `0x00`
     or `0x01` produces an invalid value, which is immediate undefined behavior.
     
     The `AsMut<[u8]>` implementation has the same problem, as it allows safe code
     to write invalid bit patterns into the backing store through the returned slice.
     
     No fixed version is available, as the crate is unmaintained; its GitHub
     repository was archived by the owner on 2026-05-03.
   ├ Announcement: https://github.com/bodil/bitmaps/issues/35
   ├ Solution: No safe upgrade is available!
   ├ bitmaps v3.2.1
     └── libdd-profiling v1.0.0
         ├── (dev) libdd-profiling v1.0.0 (*)
         └── libdd-profiling-ffi v1.0.0

error[unmaintained]: bitmaps is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:20:1
   │
20 │ bitmaps 3.2.1 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2026-0247
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0247
   ├ The bitmaps crate is unmaintained; all versions are affected. The GitHub
     repository was archived by the owner on 2026-05-03.
     
     Recommended alternatives:
     
     * [fixedbitset](https://crates.io/crates/fixedbitset)
     * [bitvec](https://crates.io/crates/bitvec)
   ├ Announcement: https://github.com/bodil/bitmaps
   ├ Solution: No safe upgrade is available!
   ├ bitmaps v3.2.1
     └── libdd-profiling v1.0.0
         ├── (dev) libdd-profiling v1.0.0 (*)
         └── libdd-profiling-ffi v1.0.0

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:91:1
   │
91 │ 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 v6.0.0
             │   ├── libdd-common-ffi v44.0.0
             │   │   └── libdd-profiling-ffi v1.0.0
             │   ├── libdd-profiling v1.0.0
             │   │   ├── (dev) libdd-profiling v1.0.0 (*)
             │   │   └── libdd-profiling-ffi v1.0.0 (*)
             │   └── libdd-profiling-ffi v1.0.0 (*)
             └── libdd-profiling v1.0.0 (*)

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:91:1
   │
91 │ 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 v6.0.0
             │   ├── libdd-common-ffi v44.0.0
             │   │   └── libdd-profiling-ffi v1.0.0
             │   ├── libdd-profiling v1.0.0
             │   │   ├── (dev) libdd-profiling v1.0.0 (*)
             │   │   └── libdd-profiling-ffi v1.0.0 (*)
             │   └── libdd-profiling-ffi v1.0.0 (*)
             └── libdd-profiling v1.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 `libdd-profiling` - 4 error(s)

Show output

error[unsound]: `Bitmap::try_from(&[u8])` can create invalid values
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:15:1
   │
15 │ bitmaps 3.2.1 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2025-0167
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0167
   ├ The `TryFrom<&[u8]>` implementation for `Bitmap<SIZE>` copies the input bytes
     into an uninitialized backing store and calls `assume_init()` without
     validating that the bytes form a valid value of the backing store type. For
     `SIZE = 1` the backing store is a `bool`, so any input byte other than `0x00`
     or `0x01` produces an invalid value, which is immediate undefined behavior.
     
     The `AsMut<[u8]>` implementation has the same problem, as it allows safe code
     to write invalid bit patterns into the backing store through the returned slice.
     
     No fixed version is available, as the crate is unmaintained; its GitHub
     repository was archived by the owner on 2026-05-03.
   ├ Announcement: https://github.com/bodil/bitmaps/issues/35
   ├ Solution: No safe upgrade is available!
   ├ bitmaps v3.2.1
     └── libdd-profiling v1.0.0
         └── (dev) libdd-profiling v1.0.0 (*)

error[unmaintained]: bitmaps is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:15:1
   │
15 │ bitmaps 3.2.1 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2026-0247
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0247
   ├ The bitmaps crate is unmaintained; all versions are affected. The GitHub
     repository was archived by the owner on 2026-05-03.
     
     Recommended alternatives:
     
     * [fixedbitset](https://crates.io/crates/fixedbitset)
     * [bitvec](https://crates.io/crates/bitvec)
   ├ Announcement: https://github.com/bodil/bitmaps
   ├ Solution: No safe upgrade is available!
   ├ bitmaps v3.2.1
     └── libdd-profiling v1.0.0
         └── (dev) libdd-profiling v1.0.0 (*)

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:80:1
   │
80 │ 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 v6.0.0
             │   └── libdd-profiling v1.0.0
             │       └── (dev) libdd-profiling v1.0.0 (*)
             └── libdd-profiling v1.0.0 (*)

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:80:1
   │
80 │ 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 v6.0.0
             │   └── libdd-profiling v1.0.0
             │       └── (dev) libdd-profiling v1.0.0 (*)
             └── libdd-profiling v1.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 `libdd-remote-config` - ✅ No issues

📦 `libdd-telemetry-ffi` - 1 error(s)

Show output

error[unmaintained]: paste - no longer maintained
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:174:1
    │
174 │ paste 1.0.15 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
    │
    ├ ID: RUSTSEC-2024-0436
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0436
    ├ The creator of the crate `paste` has stated in the [`README.md`](https://github.com/dtolnay/paste/blob/master/README.md) 
      that this project is not longer maintained as well as archived the repository
      
      ## Possible Alternative(s)
      
      - [`pastey`]: a fork of paste and is aimed to be a drop-in replacement with additional features for paste crate
      - [`with_builtin_macros`]: crate providing a [superset of `paste`'s functionality including general `macro_rules!` eager expansions](https://docs.rs/with_builtin_macros/0.1.0/with_builtin_macros/macro.with_eager_expansions.html)  and `concat!`/`concat_idents!` macros
      
      [`pastey`]: https://crates.io/crates/pastey
      [`with_builtin_macros`]: https://crates.io/crates/with_builtin_macros
    ├ Announcement: https://github.com/dtolnay/paste
    ├ Solution: No safe upgrade is available!
    ├ paste v1.0.15
      └── libdd-telemetry-ffi v44.0.0

advisories FAILED, bans ok, sources ok

📦 `libdd-telemetry` - ✅ No issues

📦 `libdd-trace-stats` - ✅ No issues

📦 `test_spawn_from_lib` - ✅ No issues

Updated: 2026-09-11 14:46:33 UTC | Commit: 2aa26ef | dependency-check job results

github-actions · 2026-09-11T12:28:19Z

📚 Documentation Check Results

⚠️ 18900 documentation warning(s) found

📦 `bin_tests` - 1224 warning(s)

📦 `build_common` - 3 warning(s)

📦 `datadog-sidecar-ffi` - 3227 warning(s)

📦 `datadog-sidecar` - 2938 warning(s)

📦 `libdd-agent-client` - 124 warning(s)

📦 `libdd-common` - 169 warning(s)

📦 `libdd-crashtracker-ffi` - 1284 warning(s)

📦 `libdd-data-pipeline` - 1304 warning(s)

📦 `libdd-ffe` - 387 warning(s)

📦 `libdd-ipc` - 1029 warning(s)

📦 `libdd-library-config-ffi` - 578 warning(s)

📦 `libdd-library-config` - 265 warning(s)

📦 `libdd-live-debugger-ffi` - 1961 warning(s)

📦 `libdd-profiling-ffi` - 770 warning(s)

📦 `libdd-profiling` - 649 warning(s)

📦 `libdd-remote-config` - 682 warning(s)

📦 `libdd-telemetry-ffi` - 734 warning(s)

📦 `libdd-telemetry` - 570 warning(s)

📦 `libdd-trace-stats` - 924 warning(s)

📦 `test_spawn_from_lib` - 78 warning(s)

Updated: 2026-09-11 14:47:26 UTC | Commit: 2aa26ef | missing-docs job results

datadog-official · 2026-09-11T12:39:19Z

✅ All CI checks and tests passed.

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 77.84% (+0.06%)

_{This comment will be updated automatically if new data arrives.

🔗 Commit SHA: f0bca2c | Docs | View more details | Give us feedback!}

dd-octo-sts · 2026-09-11T12:56:47Z

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	9.02 MB	9.02 MB	0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	96.01 MB	96.02 MB	+.01% (+10.07 KB) 🔍

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	12.19 MB	12.18 MB	-0% (-120 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	107.42 MB	107.41 MB	-0% (-3.22 KB) 👌

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	29.04 MB	29.04 MB	-0% (-1.00 KB) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	96.08 KB	96.08 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	191.77 MB	191.78 MB	+0% (+8.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	818.19 MB	818.02 MB	--.02% (-175.20 KB) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	9.69 MB	9.69 MB	--.01% (-1.00 KB) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	96.08 KB	96.08 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	27.51 MB	27.51 MB	+.02% (+8.00 KB) 🔍
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	55.57 MB	55.57 MB	-0% (-1.07 KB) 👌

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	25.41 MB	25.41 MB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	97.58 KB	97.58 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	197.08 MB	197.08 MB	-0% (-8.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	800.48 MB	799.59 MB	--.11% (-911.64 KB) 💪
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	7.51 MB	7.51 MB	-0% (-512 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	97.58 KB	97.58 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	29.63 MB	29.63 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	52.55 MB	52.54 MB	-0% (-3.43 KB) 👌

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	85.97 MB	85.97 MB	+0% (+1.73 KB) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	10.03 MB	10.03 MB	0% (0 B) 👌

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	101.85 MB	101.85 MB	+0% (+2.04 KB) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	12.25 MB	12.25 MB	+0% (+328 B) 👌

pr-commenter · 2026-09-11T13:09:33Z

Benchmarks

Comparison

Benchmark execution time: 2026-09-11 15:29:54

Comparing candidate commit f0bca2c in PR branch oscarld/remove-all-unused-dependencies-v2 with baseline commit 3f833f8 in branch main.

📊 Benchmarking dashboard

Found 6 performance improvements and 13 performance regressions! Performance is the same for 157 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 [+300.209µs; +302.687µs] or [+7.478%; +7.540%]

scenario:otlp/encode_json/1x1000

🟥 execution_time [+312.540µs; +313.077µs] or [+18.710%; +18.742%]

scenario:otlp/encode_protobuf/1x1000

🟩 execution_time [-58.843µs; -56.586µs] or [-5.294%; -5.091%]

scenario:profile_serialize_compressed_pprof_timestamped_x1000

🟥 execution_time [+67.157µs; +68.018µs] or [+7.287%; +7.380%]

scenario:span_pool/wall_time/1x10/pooled

🟥 execution_time [+145.271ns; +148.634ns] or [+7.136%; +7.302%]
🟥 throughput [-334558.229op/s; -326994.457op/s] or [-6.810%; -6.656%]

scenario:vec_map/as_deduped_map/already_deduped/16

🟥 execution_time [+1.204ns; +1.290ns] or [+4.984%; +5.341%]

scenario:vec_map/as_deduped_map/already_deduped/8

🟥 execution_time [+1.207ns; +1.255ns] or [+8.332%; +8.659%]

scenario:vec_map/as_deduped_map/needs_dedup_1_in_4/8

🟩 execution_time [-19.502ns; -18.674ns] or [-4.681%; -4.482%]

scenario:vec_map/contains_key/64

🟩 execution_time [-184.184ns; -180.030ns] or [-4.319%; -4.221%]
🟩 throughput [+661748.389op/s; +677169.633op/s] or [+4.410%; +4.512%]

scenario:vec_map/dedup/no_duplicates/8

🟩 execution_time [-19.153ns; -14.529ns] or [-5.332%; -4.045%]

scenario:vec_map/get_hit/128

🟥 execution_time [+2.721µs; +2.731µs] or [+19.879%; +19.955%]
🟥 throughput [-1556218.208op/s; -1550350.293op/s] or [-16.640%; -16.577%]

scenario:vec_map/get_hit/16

🟥 execution_time [+14.966ns; +15.195ns] or [+6.370%; +6.468%]
🟥 throughput [-4138173.924op/s; -4077235.400op/s] or [-6.076%; -5.987%]

scenario:vec_map/get_hit/64

🟥 execution_time [+711.010ns; +715.075ns] or [+19.415%; +19.526%]
🟥 throughput [-2857360.840op/s; -2839214.877op/s] or [-16.350%; -16.246%]

scenario:vec_map/get_miss/8

🟩 execution_time [-1.841ns; -1.812ns] or [-24.489%; -24.107%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

uuid already enables getrandom/js for telemetry and data pipeline. Forward Ring's WASM support through libdd-tuf in remote config.

rustls-platform-verifier uses rustls-native-certs transitively. Keep the\ndirect dependency below 0.8.3 to avoid openssl-probe 0.2 certificate\ndirectory scanning.

chatgpt-codex-connector · 2026-09-11T15:06:03Z

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-11T15:06:01.831749Z	`f0bca2c`	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

datadog-official

More details

The removed dependencies have no remaining direct, build, target, or feature use. The lockfile and license changes agree with the manifest changes.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Datadog Autotest · Commit f0bca2c · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}

chore: remove verified unused dependencies (v2)

3f5b89d

github-actions Bot added telemetry sidecar common data-pipeline crashtracker labels Sep 11, 2026

Eldolfin mentioned this pull request Sep 11, 2026

chore!: remove all unused dependencies #2319

Closed

Eldolfin changed the title ~~chore: remove verified unused dependencies (v2)~~ chore: remove unused dependencies (v2) Sep 11, 2026

Eldolfin mentioned this pull request Sep 11, 2026

ci: check unused dependencies with cargo machete #2513

Open

chore(deps): remove redundant WASM deps

1743b8d

uuid already enables getrandom/js for telemetry and data pipeline. Forward Ring's WASM support through libdd-tuf in remote config.

Eldolfin changed the title ~~chore: remove unused dependencies (v2)~~ chore!: remove unused dependencies (v2) Sep 11, 2026

fix(common): restore native cert version pin

f0bca2c

rustls-platform-verifier uses rustls-native-certs transitively. Keep the\ndirect dependency below 0.8.3 to avoid openssl-probe 0.2 certificate\ndirectory scanning.

Eldolfin marked this pull request as ready for review September 11, 2026 15:02

Eldolfin requested review from a team as code owners September 11, 2026 15:02

Eldolfin requested review from vpellan and removed request for a team September 11, 2026 15:02

Eldolfin requested review from leoromanovsky and pavlokhrebto September 11, 2026 15:02

datadog-official Bot reviewed Sep 11, 2026

View reviewed changes

Navigation Menu

Uh oh!

chore!: remove unused dependencies (v2) - #2511

chore!: remove unused dependencies (v2)#2511
Eldolfin wants to merge 3 commits into
mainfrom
oscarld/remove-all-unused-dependencies-v2

Eldolfin commented Sep 11, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 11, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 11, 2026 •

edited

Loading

Uh oh!

datadog-official Bot commented Sep 11, 2026 •

edited by datadog-datadog-prod-us1 Bot

Loading

Uh oh!

dd-octo-sts Bot commented Sep 11, 2026 •

edited

Loading

Uh oh!

pr-commenter Bot commented Sep 11, 2026 •

edited

Loading

Explanation

More details about the CI and significant changes

Uh oh!

chatgpt-codex-connector Bot commented Sep 11, 2026

Uh oh!

datadog-official Bot left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

Eldolfin commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

Motivation

Additional Notes

How to test the change?

Uh oh!

github-actions Bot commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔒 Cargo Deny Results

📦 bin_tests - ✅ No issues

📦 build_common - ✅ No issues

📦 datadog-sidecar-ffi - 3 error(s)

📦 datadog-sidecar - 2 error(s)

📦 libdd-agent-client - 2 error(s)

📦 libdd-common - 2 error(s)

📦 libdd-crashtracker-ffi - ✅ No issues

📦 libdd-data-pipeline - ✅ No issues

📦 libdd-ffe - 2 error(s)

📦 libdd-ipc - 1 error(s)

📦 libdd-library-config-ffi - ✅ No issues

📦 libdd-library-config - ✅ No issues

📦 libdd-live-debugger-ffi - ✅ No issues

📦 libdd-profiling-ffi - 4 error(s)

📦 libdd-profiling - 4 error(s)

📦 libdd-remote-config - ✅ No issues

📦 libdd-telemetry-ffi - 1 error(s)

📦 libdd-telemetry - ✅ No issues

📦 libdd-trace-stats - ✅ No issues

📦 test_spawn_from_lib - ✅ No issues

Uh oh!

github-actions Bot commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📚 Documentation Check Results

📦 bin_tests - 1224 warning(s)

📦 build_common - 3 warning(s)

📦 datadog-sidecar-ffi - 3227 warning(s)

📦 datadog-sidecar - 2938 warning(s)

📦 libdd-agent-client - 124 warning(s)

📦 libdd-common - 169 warning(s)

📦 libdd-crashtracker-ffi - 1284 warning(s)

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

📦 libdd-ffe - 387 warning(s)

📦 libdd-ipc - 1029 warning(s)

📦 libdd-library-config-ffi - 578 warning(s)

📦 libdd-library-config - 265 warning(s)

📦 libdd-live-debugger-ffi - 1961 warning(s)

📦 libdd-profiling-ffi - 770 warning(s)

📦 libdd-profiling - 649 warning(s)

📦 libdd-remote-config - 682 warning(s)

📦 libdd-telemetry-ffi - 734 warning(s)

📦 libdd-telemetry - 570 warning(s)

📦 libdd-trace-stats - 924 warning(s)

📦 test_spawn_from_lib - 78 warning(s)

Uh oh!

datadog-official Bot commented Sep 11, 2026 • edited by datadog-datadog-prod-us1 Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dd-octo-sts Bot commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Artifact Size Benchmark Report

Uh oh!

pr-commenter Bot commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmarks

Comparison

Explanation

More details about the CI and significant changes

scenario:otlp/e2e_json/1x1000

scenario:otlp/encode_json/1x1000

scenario:otlp/encode_protobuf/1x1000

scenario:profile_serialize_compressed_pprof_timestamped_x1000

scenario:span_pool/wall_time/1x10/pooled

scenario:vec_map/as_deduped_map/already_deduped/16

scenario:vec_map/as_deduped_map/already_deduped/8

scenario:vec_map/as_deduped_map/needs_dedup_1_in_4/8

scenario:vec_map/contains_key/64

scenario:vec_map/dedup/no_duplicates/8

Eldolfin commented Sep 11, 2026 •

edited

Loading

github-actions Bot commented Sep 11, 2026 •

edited

Loading

📦 `bin_tests` - ✅ No issues

📦 `build_common` - ✅ No issues

📦 `datadog-sidecar-ffi` - 3 error(s)

📦 `datadog-sidecar` - 2 error(s)

📦 `libdd-agent-client` - 2 error(s)

📦 `libdd-common` - 2 error(s)

📦 `libdd-crashtracker-ffi` - ✅ No issues

📦 `libdd-data-pipeline` - ✅ No issues

📦 `libdd-ffe` - 2 error(s)

📦 `libdd-ipc` - 1 error(s)

📦 `libdd-library-config-ffi` - ✅ No issues

📦 `libdd-library-config` - ✅ No issues

📦 `libdd-live-debugger-ffi` - ✅ No issues

📦 `libdd-profiling-ffi` - 4 error(s)

📦 `libdd-profiling` - 4 error(s)

📦 `libdd-remote-config` - ✅ No issues

📦 `libdd-telemetry-ffi` - 1 error(s)

📦 `libdd-telemetry` - ✅ No issues

📦 `libdd-trace-stats` - ✅ No issues

📦 `test_spawn_from_lib` - ✅ No issues

github-actions Bot commented Sep 11, 2026 •

edited

Loading

📦 `bin_tests` - 1224 warning(s)

📦 `build_common` - 3 warning(s)

📦 `datadog-sidecar-ffi` - 3227 warning(s)

📦 `datadog-sidecar` - 2938 warning(s)

📦 `libdd-agent-client` - 124 warning(s)

📦 `libdd-common` - 169 warning(s)

📦 `libdd-crashtracker-ffi` - 1284 warning(s)

📦 `libdd-data-pipeline` - 1304 warning(s)

📦 `libdd-ffe` - 387 warning(s)

📦 `libdd-ipc` - 1029 warning(s)

📦 `libdd-library-config-ffi` - 578 warning(s)

📦 `libdd-library-config` - 265 warning(s)

📦 `libdd-live-debugger-ffi` - 1961 warning(s)

📦 `libdd-profiling-ffi` - 770 warning(s)

📦 `libdd-profiling` - 649 warning(s)

📦 `libdd-remote-config` - 682 warning(s)

📦 `libdd-telemetry-ffi` - 734 warning(s)

📦 `libdd-telemetry` - 570 warning(s)

📦 `libdd-trace-stats` - 924 warning(s)

📦 `test_spawn_from_lib` - 78 warning(s)

datadog-official Bot commented Sep 11, 2026 •

edited by datadog-datadog-prod-us1 Bot

Loading

dd-octo-sts Bot commented Sep 11, 2026 •

edited

Loading

pr-commenter Bot commented Sep 11, 2026 •

edited

Loading