Skip to content

refactor!: apply small timeout pooling strategy to libdd-http-client as well - #2449

Open
yannham wants to merge 6 commits into
mainfrom
yannham/periodic-pooling-api
Open

refactor!: apply small timeout pooling strategy to libdd-http-client as well#2449
yannham wants to merge 6 commits into
mainfrom
yannham/periodic-pooling-api

Conversation

@yannham

@yannham yannham commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Follow-up of #2440. Rename new_no_connection_pooling to reflect the more nuanced semantics of the function. Apply the same treatment to the equivalent functions in libdd-http-client and libdd-agent-client.

Motivation

See #2440.

How to test the change?

Tested locally on the repro mentioned in #2440.

Now that periodic clients pool connections with a small idle timeout
instead of disabling pooling entirely, "new_without_connection_pooling"
no longer describes what the constructor does. Rename it (and the
related internal fields) to "new_periodic" to match the semantics.

This is a breaking rename of the public capabilities API; all callers
across the workspace are updated accordingly.
…client and libdd-agent-client

Follow-up to the change that stopped entirely disabling connection
pooling for periodic connections in libdd-common:

- rename HttpClientBuilder::allow_connection_pooling to periodic, along
  with the HttpClientConfig getter and related fields
- periodic clients now pool connections with a small idle timeout (5s)
  instead of disabling pooling entirely, in both the reqwest and hyper
  backends
- rename AgentClientBuilder::allow_connection_pooling to periodic, now
  defaulting to true since the agent client is a periodic-flush writer by
  default
@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 9716 documentation warning(s) found

📦 datadog-live-debugger - 1658 warning(s)

📦 datadog-sidecar - 2927 warning(s)

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

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

📦 libdd-capabilities - 35 warning(s)

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

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

📦 libdd-ffe - 387 warning(s)

📦 libdd-http-client - ✅ No warnings

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

📦 libdd-telemetry - 570 warning(s)

📦 libdd-tracer-flare - 1025 warning(s)


Updated: 2026-09-03 12:45:20 UTC | Commit: 283ae69 | missing-docs job results

@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

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

📦 datadog-live-debugger - 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:78:1
   │
78 │ 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
                     │   ├── datadog-live-debugger v0.0.1
                     │   ├── libdd-capabilities-impl v4.0.0
                     │   │   ├── datadog-live-debugger v0.0.1 (*)
                     │   │   ├── libdd-data-pipeline v9.0.0
                     │   │   │   └── datadog-live-debugger v0.0.1 (*)
                     │   │   ├── libdd-remote-config v4.0.0
                     │   │   │   ├── datadog-live-debugger v0.0.1 (*)
                     │   │   │   └── (dev) libdd-remote-config v4.0.0 (*)
                     │   │   ├── libdd-shared-runtime v3.0.0
                     │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   ├── libdd-dogstatsd-client v5.0.0
                     │   │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v8.0.0
                     │   │   │   │       └── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   ├── libdd-telemetry v7.0.0
                     │   │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v8.0.0 (*)
                     │   │   │   └── libdd-trace-stats v8.0.0 (*)
                     │   │   ├── (dev) libdd-telemetry v7.0.0 (*)
                     │   │   ├── libdd-trace-stats v8.0.0 (*)
                     │   │   └── libdd-trace-utils v11.0.0
                     │   │       ├── libdd-data-pipeline v9.0.0 (*)
                     │   │       ├── libdd-data-pipeline-core v1.0.0
                     │   │       │   └── libdd-data-pipeline v9.0.0 (*)
                     │   │       ├── libdd-trace-obfuscation v7.0.0
                     │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │       │   ├── libdd-data-pipeline-core v1.0.0 (*)
                     │   │       │   └── libdd-trace-stats v8.0.0 (*)
                     │   │       ├── libdd-trace-stats v8.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v11.0.0 (*)
                     │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   ├── libdd-data-pipeline-core v1.0.0 (*)
                     │   ├── libdd-dogstatsd-client v5.0.0 (*)
                     │   ├── libdd-remote-config v4.0.0 (*)
                     │   ├── libdd-shared-runtime v3.0.0 (*)
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   ├── libdd-trace-obfuscation v7.0.0 (*)
                     │   ├── libdd-trace-stats v8.0.0 (*)
                     │   └── libdd-trace-utils v11.0.0 (*)
                     ├── (dev) libdd-data-pipeline v9.0.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.1
                     │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   └── libdd-trace-stats v8.0.0 (*)
                     ├── (dev) libdd-trace-normalization v4.0.0
                     │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   └── libdd-trace-utils v11.0.0 (*)
                     ├── (dev) libdd-trace-obfuscation v7.0.0 (*)
                     ├── (dev) libdd-trace-stats v8.0.0 (*)
                     └── (dev) libdd-trace-utils v11.0.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:123:1
    │
123 │ 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 v9.0.0
      │   │   │   └── datadog-live-debugger v0.0.1
      │   │   ├── (dev) libdd-telemetry v7.0.0
      │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   └── libdd-trace-stats v8.0.0
      │   │   │       └── libdd-data-pipeline v9.0.0 (*)
      │   │   ├── (dev) libdd-trace-stats v8.0.0 (*)
      │   │   └── libdd-trace-utils v11.0.0
      │   │       ├── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v1.0.0
      │   │       │   └── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v7.0.0
      │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   │       │   └── libdd-trace-stats v8.0.0 (*)
      │   │       ├── libdd-trace-stats v8.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v11.0.0 (*)
      │   ├── hyper-rustls v0.27.7
      │   │   └── libdd-common v5.2.0
      │   │       ├── datadog-live-debugger v0.0.1 (*)
      │   │       ├── libdd-capabilities-impl v4.0.0
      │   │       │   ├── datadog-live-debugger v0.0.1 (*)
      │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   ├── libdd-remote-config v4.0.0
      │   │       │   │   ├── datadog-live-debugger v0.0.1 (*)
      │   │       │   │   └── (dev) libdd-remote-config v4.0.0 (*)
      │   │       │   ├── libdd-shared-runtime v3.0.0
      │   │       │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   │   ├── libdd-dogstatsd-client v5.0.0
      │   │       │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   │   │   └── libdd-trace-stats v8.0.0 (*)
      │   │       │   │   ├── libdd-telemetry v7.0.0 (*)
      │   │       │   │   └── libdd-trace-stats v8.0.0 (*)
      │   │       │   ├── (dev) libdd-telemetry v7.0.0 (*)
      │   │       │   ├── libdd-trace-stats v8.0.0 (*)
      │   │       │   └── libdd-trace-utils v11.0.0 (*)
      │   │       ├── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v1.0.0 (*)
      │   │       ├── libdd-dogstatsd-client v5.0.0 (*)
      │   │       ├── libdd-remote-config v4.0.0 (*)
      │   │       ├── libdd-shared-runtime v3.0.0 (*)
      │   │       ├── libdd-telemetry v7.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v7.0.0 (*)
      │   │       ├── libdd-trace-stats v8.0.0 (*)
      │   │       └── libdd-trace-utils v11.0.0 (*)
      │   ├── hyper-util v0.1.17
      │   │   ├── httpmock v0.8.0-alpha.1 (*)
      │   │   ├── hyper-rustls v0.27.7 (*)
      │   │   ├── libdd-common v5.2.0 (*)
      │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   └── libdd-remote-config v4.0.0 (*)
      │   ├── libdd-common v5.2.0 (*)
      │   ├── libdd-data-pipeline v9.0.0 (*)
      │   ├── libdd-remote-config v4.0.0 (*)
      │   └── libdd-trace-utils v11.0.0 (*)
      └── (dev) libdd-data-pipeline v9.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:234:1
    │
234 │ 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
      │   ├── datadog-live-debugger v0.0.1
      │   ├── libdd-capabilities-impl v4.0.0
      │   │   ├── datadog-live-debugger v0.0.1 (*)
      │   │   ├── libdd-data-pipeline v9.0.0
      │   │   │   └── datadog-live-debugger v0.0.1 (*)
      │   │   ├── libdd-remote-config v4.0.0
      │   │   │   ├── datadog-live-debugger v0.0.1 (*)
      │   │   │   └── (dev) libdd-remote-config v4.0.0 (*)
      │   │   ├── libdd-shared-runtime v3.0.0
      │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   ├── libdd-dogstatsd-client v5.0.0
      │   │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v8.0.0
      │   │   │   │       └── libdd-data-pipeline v9.0.0 (*)
      │   │   │   ├── libdd-telemetry v7.0.0
      │   │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v8.0.0 (*)
      │   │   │   └── libdd-trace-stats v8.0.0 (*)
      │   │   ├── (dev) libdd-telemetry v7.0.0 (*)
      │   │   ├── libdd-trace-stats v8.0.0 (*)
      │   │   └── libdd-trace-utils v11.0.0
      │   │       ├── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v1.0.0
      │   │       │   └── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v7.0.0
      │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   │       │   └── libdd-trace-stats v8.0.0 (*)
      │   │       ├── libdd-trace-stats v8.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v11.0.0 (*)
      │   ├── libdd-data-pipeline v9.0.0 (*)
      │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   ├── libdd-dogstatsd-client v5.0.0 (*)
      │   ├── libdd-remote-config v4.0.0 (*)
      │   ├── libdd-shared-runtime v3.0.0 (*)
      │   ├── libdd-telemetry v7.0.0 (*)
      │   ├── libdd-trace-obfuscation v7.0.0 (*)
      │   ├── libdd-trace-stats v8.0.0 (*)
      │   └── libdd-trace-utils v11.0.0 (*)
      ├── (dev) libdd-data-pipeline v9.0.0 (*)
      ├── (dev) libdd-ddsketch v1.1.1
      │   ├── libdd-data-pipeline v9.0.0 (*)
      │   ├── libdd-telemetry v7.0.0 (*)
      │   └── libdd-trace-stats v8.0.0 (*)
      ├── (dev) libdd-trace-normalization v4.0.0
      │   ├── libdd-data-pipeline v9.0.0 (*)
      │   └── libdd-trace-utils v11.0.0 (*)
      ├── (dev) libdd-trace-stats v8.0.0 (*)
      ├── libdd-trace-utils v11.0.0 (*)
      └── proptest v1.5.0
          ├── (dev) libdd-common v5.2.0 (*)
          └── (dev) libdd-tinybytes v1.1.2
              ├── libdd-data-pipeline v9.0.0 (*)
              ├── (dev) libdd-data-pipeline-core v1.0.0 (*)
              ├── (dev) libdd-tinybytes v1.1.2 (*)
              ├── (dev) libdd-trace-obfuscation v7.0.0 (*)
              └── libdd-trace-utils v11.0.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:309:1
    │
309 │ 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
      ├── libdd-remote-config v4.0.0
      │   ├── datadog-live-debugger v0.0.1
      │   └── (dev) libdd-remote-config v4.0.0 (*)
      └── tracing-appender v0.2.3
          └── libdd-log v1.0.0
              └── (dev) libdd-data-pipeline v9.0.0
                  └── datadog-live-debugger v0.0.1 (*)

advisories FAILED, bans ok, sources ok

📦 datadog-sidecar - 6 error(s)

Show output
error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:37:1
   │
37 │ 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 v1.0.0
     │   └── datadog-sidecar v0.0.1 (*)
     └── libdd-ipc v1.0.0
         └── datadog-sidecar v0.0.1 (*)

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:92:1
   │
92 │ 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
                     │   ├── datadog-live-debugger v0.0.1
                     │   │   └── datadog-sidecar v0.0.1
                     │   ├── datadog-sidecar v0.0.1 (*)
                     │   ├── libdd-capabilities-impl v4.0.0
                     │   │   ├── datadog-live-debugger v0.0.1 (*)
                     │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   ├── libdd-crashtracker v2.0.1
                     │   │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   └── libdd-crashtracker-ffi v43.0.0
                     │   │   │       └── datadog-sidecar v0.0.1 (*)
                     │   │   ├── libdd-data-pipeline v9.0.0
                     │   │   │   ├── datadog-live-debugger v0.0.1 (*)
                     │   │   │   └── datadog-sidecar v0.0.1 (*)
                     │   │   ├── (dev) libdd-ffe v1.0.0
                     │   │   │   └── datadog-sidecar v0.0.1 (*)
                     │   │   ├── libdd-remote-config v4.0.0
                     │   │   │   ├── datadog-live-debugger v0.0.1 (*)
                     │   │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
                     │   │   │   ├── libdd-ffe v1.0.0 (*)
                     │   │   │   └── (dev) libdd-remote-config v4.0.0 (*)
                     │   │   ├── libdd-shared-runtime v3.0.0
                     │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   ├── libdd-dogstatsd-client v5.0.0
                     │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v8.0.0
                     │   │   │   │       ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   │       ├── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   │       └── libdd-ipc v1.0.0
                     │   │   │   │           └── datadog-sidecar v0.0.1 (*)
                     │   │   │   ├── libdd-telemetry v7.0.0
                     │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   │   ├── libdd-crashtracker v2.0.1 (*)
                     │   │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v8.0.0 (*)
                     │   │   │   └── libdd-trace-stats v8.0.0 (*)
                     │   │   ├── (dev) libdd-telemetry v7.0.0 (*)
                     │   │   ├── libdd-trace-stats v8.0.0 (*)
                     │   │   └── libdd-trace-utils v11.0.0
                     │   │       ├── (dev) datadog-sidecar v0.0.1 (*)
                     │   │       ├── libdd-data-pipeline v9.0.0 (*)
                     │   │       ├── libdd-data-pipeline-core v1.0.0
                     │   │       │   └── libdd-data-pipeline v9.0.0 (*)
                     │   │       ├── libdd-trace-obfuscation v7.0.0
                     │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │       │   ├── libdd-data-pipeline-core v1.0.0 (*)
                     │   │       │   └── libdd-trace-stats v8.0.0 (*)
                     │   │       ├── libdd-trace-stats v8.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v11.0.0 (*)
                     │   ├── libdd-common-ffi v43.0.0
                     │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   └── libdd-crashtracker-ffi v43.0.0 (*)
                     │   ├── (build) libdd-crashtracker v2.0.1 (*)
                     │   ├── libdd-crashtracker-ffi v43.0.0 (*)
                     │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   ├── libdd-data-pipeline-core v1.0.0 (*)
                     │   ├── libdd-dogstatsd-client v5.0.0 (*)
                     │   ├── libdd-ffe v1.0.0 (*)
                     │   ├── libdd-ipc v1.0.0 (*)
                     │   ├── libdd-remote-config v4.0.0 (*)
                     │   ├── libdd-shared-runtime v3.0.0 (*)
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   ├── libdd-trace-obfuscation v7.0.0 (*)
                     │   ├── libdd-trace-stats v8.0.0 (*)
                     │   └── libdd-trace-utils v11.0.0 (*)
                     ├── (dev) libdd-crashtracker v2.0.1 (*)
                     ├── (dev) libdd-data-pipeline v9.0.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.1
                     │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   ├── libdd-ipc v1.0.0 (*)
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   └── libdd-trace-stats v8.0.0 (*)
                     ├── (dev) libdd-ipc v1.0.0 (*)
                     ├── (dev) libdd-trace-normalization v4.0.0
                     │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   └── libdd-trace-utils v11.0.0 (*)
                     ├── (dev) libdd-trace-obfuscation v7.0.0 (*)
                     ├── (dev) libdd-trace-stats v8.0.0 (*)
                     └── (dev) libdd-trace-utils v11.0.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:154:1
    │
154 │ 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) datadog-sidecar v0.0.1
      │   │   ├── (dev) libdd-data-pipeline v9.0.0
      │   │   │   ├── datadog-live-debugger v0.0.1
      │   │   │   │   └── datadog-sidecar v0.0.1 (*)
      │   │   │   └── datadog-sidecar v0.0.1 (*)
      │   │   ├── (dev) libdd-ffe v1.0.0
      │   │   │   └── datadog-sidecar v0.0.1 (*)
      │   │   ├── (dev) libdd-telemetry v7.0.0
      │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   ├── libdd-crashtracker v2.0.1
      │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │   └── libdd-crashtracker-ffi v43.0.0
      │   │   │   │       └── datadog-sidecar v0.0.1 (*)
      │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   └── libdd-trace-stats v8.0.0
      │   │   │       ├── datadog-sidecar v0.0.1 (*)
      │   │   │       ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │       └── libdd-ipc v1.0.0
      │   │   │           └── datadog-sidecar v0.0.1 (*)
      │   │   ├── (dev) libdd-trace-stats v8.0.0 (*)
      │   │   └── libdd-trace-utils v11.0.0
      │   │       ├── (dev) datadog-sidecar v0.0.1 (*)
      │   │       ├── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v1.0.0
      │   │       │   └── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v7.0.0
      │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   │       │   └── libdd-trace-stats v8.0.0 (*)
      │   │       ├── libdd-trace-stats v8.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v11.0.0 (*)
      │   ├── hyper-rustls v0.27.7
      │   │   └── libdd-common v5.2.0
      │   │       ├── datadog-live-debugger v0.0.1 (*)
      │   │       ├── datadog-sidecar v0.0.1 (*)
      │   │       ├── libdd-capabilities-impl v4.0.0
      │   │       │   ├── datadog-live-debugger v0.0.1 (*)
      │   │       │   ├── datadog-sidecar v0.0.1 (*)
      │   │       │   ├── libdd-crashtracker v2.0.1 (*)
      │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   ├── (dev) libdd-ffe v1.0.0 (*)
      │   │       │   ├── libdd-remote-config v4.0.0
      │   │       │   │   ├── datadog-live-debugger v0.0.1 (*)
      │   │       │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
      │   │       │   │   ├── libdd-ffe v1.0.0 (*)
      │   │       │   │   └── (dev) libdd-remote-config v4.0.0 (*)
      │   │       │   ├── libdd-shared-runtime v3.0.0
      │   │       │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   │   ├── libdd-dogstatsd-client v5.0.0
      │   │       │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │       │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   │   │   └── libdd-trace-stats v8.0.0 (*)
      │   │       │   │   ├── libdd-telemetry v7.0.0 (*)
      │   │       │   │   └── libdd-trace-stats v8.0.0 (*)
      │   │       │   ├── (dev) libdd-telemetry v7.0.0 (*)
      │   │       │   ├── libdd-trace-stats v8.0.0 (*)
      │   │       │   └── libdd-trace-utils v11.0.0 (*)
      │   │       ├── libdd-common-ffi v43.0.0
      │   │       │   ├── datadog-sidecar v0.0.1 (*)
      │   │       │   └── libdd-crashtracker-ffi v43.0.0 (*)
      │   │       ├── (build) libdd-crashtracker v2.0.1 (*)
      │   │       ├── libdd-crashtracker-ffi v43.0.0 (*)
      │   │       ├── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v1.0.0 (*)
      │   │       ├── libdd-dogstatsd-client v5.0.0 (*)
      │   │       ├── libdd-ffe v1.0.0 (*)
      │   │       ├── libdd-ipc v1.0.0 (*)
      │   │       ├── libdd-remote-config v4.0.0 (*)
      │   │       ├── libdd-shared-runtime v3.0.0 (*)
      │   │       ├── libdd-telemetry v7.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v7.0.0 (*)
      │   │       ├── libdd-trace-stats v8.0.0 (*)
      │   │       └── libdd-trace-utils v11.0.0 (*)
      │   ├── hyper-util v0.1.17
      │   │   ├── httpmock v0.8.0-alpha.1 (*)
      │   │   ├── hyper-rustls v0.27.7 (*)
      │   │   ├── libdd-common v5.2.0 (*)
      │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   └── libdd-remote-config v4.0.0 (*)
      │   ├── libdd-common v5.2.0 (*)
      │   ├── libdd-common-ffi v43.0.0 (*)
      │   ├── libdd-data-pipeline v9.0.0 (*)
      │   ├── libdd-remote-config v4.0.0 (*)
      │   └── libdd-trace-utils v11.0.0 (*)
      └── (dev) libdd-data-pipeline v9.0.0 (*)

error[unsound]: Potential use-after-free due to lack of panic safety in `LruCache::pop()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:235:1
    │
235 │ 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 v1.0.0
          └── datadog-sidecar v0.0.1

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:310:1
    │
310 │ 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
      ├── datadog-sidecar v0.0.1
      ├── libdd-common v5.2.0
      │   ├── datadog-live-debugger v0.0.1
      │   │   └── datadog-sidecar v0.0.1 (*)
      │   ├── datadog-sidecar v0.0.1 (*)
      │   ├── libdd-capabilities-impl v4.0.0
      │   │   ├── datadog-live-debugger v0.0.1 (*)
      │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   ├── libdd-crashtracker v2.0.1
      │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   └── libdd-crashtracker-ffi v43.0.0
      │   │   │       └── datadog-sidecar v0.0.1 (*)
      │   │   ├── libdd-data-pipeline v9.0.0
      │   │   │   ├── datadog-live-debugger v0.0.1 (*)
      │   │   │   └── datadog-sidecar v0.0.1 (*)
      │   │   ├── (dev) libdd-ffe v1.0.0
      │   │   │   └── datadog-sidecar v0.0.1 (*)
      │   │   ├── libdd-remote-config v4.0.0
      │   │   │   ├── datadog-live-debugger v0.0.1 (*)
      │   │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
      │   │   │   ├── libdd-ffe v1.0.0 (*)
      │   │   │   └── (dev) libdd-remote-config v4.0.0 (*)
      │   │   ├── libdd-shared-runtime v3.0.0
      │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   ├── libdd-dogstatsd-client v5.0.0
      │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v8.0.0
      │   │   │   │       ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │       ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   │       └── libdd-ipc v1.0.0
      │   │   │   │           └── datadog-sidecar v0.0.1 (*)
      │   │   │   ├── libdd-telemetry v7.0.0
      │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │   ├── libdd-crashtracker v2.0.1 (*)
      │   │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v8.0.0 (*)
      │   │   │   └── libdd-trace-stats v8.0.0 (*)
      │   │   ├── (dev) libdd-telemetry v7.0.0 (*)
      │   │   ├── libdd-trace-stats v8.0.0 (*)
      │   │   └── libdd-trace-utils v11.0.0
      │   │       ├── (dev) datadog-sidecar v0.0.1 (*)
      │   │       ├── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v1.0.0
      │   │       │   └── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v7.0.0
      │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   │       │   └── libdd-trace-stats v8.0.0 (*)
      │   │       ├── libdd-trace-stats v8.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v11.0.0 (*)
      │   ├── libdd-common-ffi v43.0.0
      │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   └── libdd-crashtracker-ffi v43.0.0 (*)
      │   ├── (build) libdd-crashtracker v2.0.1 (*)
      │   ├── libdd-crashtracker-ffi v43.0.0 (*)
      │   ├── libdd-data-pipeline v9.0.0 (*)
      │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   ├── libdd-dogstatsd-client v5.0.0 (*)
      │   ├── libdd-ffe v1.0.0 (*)
      │   ├── libdd-ipc v1.0.0 (*)
      │   ├── libdd-remote-config v4.0.0 (*)
      │   ├── libdd-shared-runtime v3.0.0 (*)
      │   ├── libdd-telemetry v7.0.0 (*)
      │   ├── libdd-trace-obfuscation v7.0.0 (*)
      │   ├── libdd-trace-stats v8.0.0 (*)
      │   └── libdd-trace-utils v11.0.0 (*)
      ├── libdd-crashtracker v2.0.1 (*)
      ├── (dev) libdd-data-pipeline v9.0.0 (*)
      ├── (dev) libdd-ddsketch v1.1.1
      │   ├── libdd-data-pipeline v9.0.0 (*)
      │   ├── libdd-ipc v1.0.0 (*)
      │   ├── libdd-telemetry v7.0.0 (*)
      │   └── libdd-trace-stats v8.0.0 (*)
      ├── (dev) libdd-trace-normalization v4.0.0
      │   ├── libdd-data-pipeline v9.0.0 (*)
      │   └── libdd-trace-utils v11.0.0 (*)
      ├── (dev) libdd-trace-stats v8.0.0 (*)
      ├── libdd-trace-utils v11.0.0 (*)
      └── proptest v1.5.0
          ├── (dev) libdd-common v5.2.0 (*)
          └── (dev) libdd-tinybytes v1.1.2
              ├── datadog-sidecar v0.0.1 (*)
              ├── libdd-data-pipeline v9.0.0 (*)
              ├── (dev) libdd-data-pipeline-core v1.0.0 (*)
              ├── libdd-ipc v1.0.0 (*)
              ├── (dev) libdd-tinybytes v1.1.2 (*)
              ├── (dev) libdd-trace-obfuscation v7.0.0 (*)
              └── libdd-trace-utils v11.0.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:405:1
    │
405 │ 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
      ├── libdd-remote-config v4.0.0
      │   ├── datadog-live-debugger v0.0.1
      │   │   └── datadog-sidecar v0.0.1
      │   ├── (dev) datadog-sidecar v0.0.1 (*)
      │   ├── libdd-ffe v1.0.0
      │   │   └── datadog-sidecar v0.0.1 (*)
      │   └── (dev) libdd-remote-config v4.0.0 (*)
      └── tracing-appender v0.2.3
          └── libdd-log v1.0.0
              └── (dev) libdd-data-pipeline v9.0.0
                  ├── datadog-live-debugger v0.0.1 (*)
                  └── datadog-sidecar v0.0.1 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-agent-client - 5 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:44:1
   │
44 │ 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
                     └── libdd-agent-client v43.0.0

error[vulnerability]: h2 unbounded empty DATA frames
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:77:1
   │
77 │ 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-agent-client v43.0.0
         │   └── (dev) libdd-http-client v1.0.0
         │       └── libdd-agent-client v43.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:85:1
   │
85 │ 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
                 └── libdd-agent-client v43.0.0

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

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:157:1
    │
157 │ 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-agent-client v43.0.0
      └── proptest v1.5.0
          └── (dev) libdd-common v5.2.0 (*)

advisories FAILED, bans ok, sources ok

📦 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-capabilities - ✅ No issues

📦 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:64:1
   │
64 │ 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 v11.0.0
                     │   │       ├── libdd-data-pipeline-core v1.0.0
                     │   │       ├── libdd-trace-obfuscation v7.0.0
                     │   │       │   └── libdd-data-pipeline-core v1.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v11.0.0 (*)
                     │   ├── libdd-data-pipeline-core v1.0.0 (*)
                     │   ├── libdd-trace-obfuscation v7.0.0 (*)
                     │   └── libdd-trace-utils v11.0.0 (*)
                     ├── (dev) libdd-trace-normalization v4.0.0
                     │   └── libdd-trace-utils v11.0.0 (*)
                     ├── (dev) libdd-trace-obfuscation v7.0.0 (*)
                     └── (dev) libdd-trace-utils v11.0.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:101:1
    │
101 │ 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 v11.0.0
          │       ├── libdd-data-pipeline-core v1.0.0
          │       ├── libdd-trace-obfuscation v7.0.0
          │       │   └── libdd-data-pipeline-core v1.0.0 (*)
          │       └── (dev) libdd-trace-utils v11.0.0 (*)
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v5.2.0
          │       ├── libdd-capabilities-impl v4.0.0
          │       │   └── libdd-trace-utils v11.0.0 (*)
          │       ├── libdd-data-pipeline-core v1.0.0 (*)
          │       ├── libdd-trace-obfuscation v7.0.0 (*)
          │       └── libdd-trace-utils v11.0.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 v11.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:192:1
    │
192 │ 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 v11.0.0
      │   │       ├── libdd-data-pipeline-core v1.0.0
      │   │       ├── libdd-trace-obfuscation v7.0.0
      │   │       │   └── libdd-data-pipeline-core v1.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v11.0.0 (*)
      │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   ├── libdd-trace-obfuscation v7.0.0 (*)
      │   └── libdd-trace-utils v11.0.0 (*)
      ├── (dev) libdd-trace-normalization v4.0.0
      │   └── libdd-trace-utils v11.0.0 (*)
      ├── libdd-trace-utils v11.0.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 (*)
              ├── (dev) libdd-trace-obfuscation v7.0.0 (*)
              └── libdd-trace-utils v11.0.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 v9.0.0
                     │   │   ├── libdd-shared-runtime v3.0.0
                     │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   ├── libdd-dogstatsd-client v5.0.0
                     │   │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v8.0.0
                     │   │   │   │       └── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   ├── libdd-telemetry v7.0.0
                     │   │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v8.0.0 (*)
                     │   │   │   └── libdd-trace-stats v8.0.0 (*)
                     │   │   ├── (dev) libdd-telemetry v7.0.0 (*)
                     │   │   ├── libdd-trace-stats v8.0.0 (*)
                     │   │   └── libdd-trace-utils v11.0.0
                     │   │       ├── libdd-data-pipeline v9.0.0 (*)
                     │   │       ├── libdd-data-pipeline-core v1.0.0
                     │   │       │   └── libdd-data-pipeline v9.0.0 (*)
                     │   │       ├── libdd-trace-obfuscation v7.0.0
                     │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │       │   ├── libdd-data-pipeline-core v1.0.0 (*)
                     │   │       │   └── libdd-trace-stats v8.0.0 (*)
                     │   │       ├── libdd-trace-stats v8.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v11.0.0 (*)
                     │   ├── libdd-data-pipeline v9.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 v7.0.0 (*)
                     │   ├── libdd-trace-stats v8.0.0 (*)
                     │   └── libdd-trace-utils v11.0.0 (*)
                     ├── (dev) libdd-data-pipeline v9.0.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.1
                     │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   └── libdd-trace-stats v8.0.0 (*)
                     ├── (dev) libdd-trace-normalization v4.0.0
                     │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   └── libdd-trace-utils v11.0.0 (*)
                     ├── (dev) libdd-trace-obfuscation v7.0.0 (*)
                     ├── (dev) libdd-trace-stats v8.0.0 (*)
                     └── (dev) libdd-trace-utils v11.0.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 v9.0.0
      │   │   ├── (dev) libdd-telemetry v7.0.0
      │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   └── libdd-trace-stats v8.0.0
      │   │   │       └── libdd-data-pipeline v9.0.0 (*)
      │   │   ├── (dev) libdd-trace-stats v8.0.0 (*)
      │   │   └── libdd-trace-utils v11.0.0
      │   │       ├── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v1.0.0
      │   │       │   └── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v7.0.0
      │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   │       │   └── libdd-trace-stats v8.0.0 (*)
      │   │       ├── libdd-trace-stats v8.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v11.0.0 (*)
      │   ├── hyper-rustls v0.27.7
      │   │   └── libdd-common v5.2.0
      │   │       ├── libdd-capabilities-impl v4.0.0
      │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   ├── libdd-shared-runtime v3.0.0
      │   │       │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   │   ├── libdd-dogstatsd-client v5.0.0
      │   │       │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   │   │   └── libdd-trace-stats v8.0.0 (*)
      │   │       │   │   ├── libdd-telemetry v7.0.0 (*)
      │   │       │   │   └── libdd-trace-stats v8.0.0 (*)
      │   │       │   ├── (dev) libdd-telemetry v7.0.0 (*)
      │   │       │   ├── libdd-trace-stats v8.0.0 (*)
      │   │       │   └── libdd-trace-utils v11.0.0 (*)
      │   │       ├── libdd-data-pipeline v9.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 v7.0.0 (*)
      │   │       ├── libdd-trace-stats v8.0.0 (*)
      │   │       └── libdd-trace-utils v11.0.0 (*)
      │   ├── hyper-util v0.1.17
      │   │   ├── httpmock v0.8.0-alpha.1 (*)
      │   │   ├── hyper-rustls v0.27.7 (*)
      │   │   ├── libdd-common v5.2.0 (*)
      │   │   └── libdd-data-pipeline v9.0.0 (*)
      │   ├── libdd-common v5.2.0 (*)
      │   ├── libdd-data-pipeline v9.0.0 (*)
      │   └── libdd-trace-utils v11.0.0 (*)
      └── (dev) libdd-data-pipeline v9.0.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 ...*[Comment body truncated]*

@yannham
yannham marked this pull request as ready for review September 3, 2026 09:18
@yannham
yannham requested review from a team as code owners September 3, 2026 09:18
@yannham
yannham requested review from btthomas and typotter and removed request for a team September 3, 2026 09:18
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 3, 2026

Copy link
Copy Markdown

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-03T09:22:10.817222Z f3f9707 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

datadog-official Bot commented Sep 3, 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: 80.60%
Overall Coverage: 77.09% (+0.01%)

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

@datadog-official datadog-official 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.

Datadog Autotest: FAIL

Periodic clients can keep an unlimited number of idle sockets for five seconds after a concurrent request burst. The existing periodic client limits this pool to 20 sockets.

Open Bits AI session

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

// while avoiding reusing connections the receiver may have closed.
builder
.pool_timer(hyper_util::rt::TokioTimer::new())
.pool_idle_timeout(crate::config::PERIODIC_POOL_IDLE_TIMEOUT);

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 Limit periodic idle connection pools

A concurrent request burst can keep many idle sockets open and cause short-term resource pressure.

Assertion details
  • Input: A periodic client sends many concurrent requests to the same host.
  • Expected: Periodic clients must limit idle connections per host. The existing periodic client uses a limit of 20.
  • Actual: The hyper and reqwest backends use the default unlimited idle-pool limit. They keep each socket until the five-second timeout ends.

Was this helpful? React 👍 or 👎
🤖 Datadog Autotest · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest · Open Bits AI session

@pr-commenter

pr-commenter Bot commented Sep 3, 2026

Copy link
Copy Markdown

Benchmarks

Comparison

Benchmark execution time: 2026-09-03 13:16:49

Comparing candidate commit 0e5310f in PR branch yannham/periodic-pooling-api with baseline commit efbbf4c in branch main.

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

Explanation

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

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

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

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

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

More details about the CI and significant changes

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

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

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

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

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

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

scenario:vec_map/as_deduped_map/needs_dedup_1_in_4/8

  • 🟩 execution_time [-17.985ns; -17.743ns] or [-4.387%; -4.328%]

Benchmark execution time: 2026-09-03 13:15:27

Comparing candidate commit 0e5310f in PR branch yannham/periodic-pooling-api with baseline commit efbbf4c in branch main.

Found 9 performance improvements and 3 performance regressions! Performance is the same for 64 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:datadog_sample_span/complex_rule_matching/wall_time

  • 🟩 execution_time [-66.210ns; -65.847ns] or [-10.195%; -10.139%]

scenario:datadog_sample_span/many_attributes_tag_rule/wall_time

  • 🟩 execution_time [-50.148ns; -49.952ns] or [-12.703%; -12.654%]

scenario:datadog_sample_span/multiple_rules_first_match/wall_time

  • 🟩 execution_time [-17.304ns; -17.039ns] or [-9.700%; -9.551%]

scenario:datadog_sample_span/multiple_rules_last_match/wall_time

  • 🟩 execution_time [-13.709ns; -13.563ns] or [-6.449%; -6.380%]

scenario:datadog_sample_span/name_pattern_rule_matching/wall_time

  • 🟩 execution_time [-16.361ns; -16.203ns] or [-5.844%; -5.787%]

scenario:datadog_sample_span/resource_pattern_rule_matching/wall_time

  • 🟩 execution_time [-18.240ns; -18.049ns] or [-6.638%; -6.568%]

scenario:datadog_sample_span/service_rule_matching/wall_time

  • 🟩 execution_time [-17.643ns; -17.433ns] or [-6.577%; -6.499%]

scenario:datadog_sample_span/tag_rule_matching/wall_time

  • 🟩 execution_time [-49.644ns; -49.451ns] or [-13.083%; -13.032%]

scenario:glob_matcher/unicode_pattern_ascii_subject/wall_time

  • 🟥 execution_time [+12.726ns; +12.774ns] or [+14.051%; +14.104%]

scenario:trace_buffer/2_senders/no_delay

  • 🟥 execution_time [+167.905µs; +181.862µs] or [+11.101%; +12.024%]
  • 🟥 throughput [-127977.681op/s; -118352.335op/s] or [-10.750%; -9.941%]

scenario:trace_buffer/4_senders/no_delay

  • 🟩 throughput [+38735.592op/s; +42463.871op/s] or [+4.078%; +4.471%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

@dd-octo-sts

dd-octo-sts Bot commented Sep 3, 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.a 91.30 MB 91.30 MB -0% (-512 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 8.45 MB 8.45 MB 0% (0 B) 👌
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 102.61 MB 102.61 MB -0% (-176 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.38 MB 11.38 MB -0% (-40 B) 👌
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 27.33 MB 27.33 MB 0% (0 B) 👌
/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 185.41 MB 185.41 MB +0% (+8.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 805.24 MB 805.23 MB -0% (-2.14 KB) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 9.01 MB 9.01 MB 0% (0 B) 👌
/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 26.21 MB 26.21 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 52.22 MB 52.22 MB -0% (-136 B) 👌
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 23.82 MB 23.82 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 190.43 MB 190.43 MB 0% (0 B) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 788.61 MB 788.61 MB -0% (-2.15 KB) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 6.96 MB 6.96 MB 0% (0 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 28.19 MB 28.18 MB --.02% (-8.00 KB) 💪
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 49.70 MB 49.70 MB -0% (-128 B) 👌
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 81.45 MB 81.45 MB -0% (-192 B) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 9.41 MB 9.41 MB 0% (0 B) 👌
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 97.22 MB 97.22 MB -0% (-176 B) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.46 MB 11.46 MB -0% (-16 B) 👌

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Changes recommended

There are a few documentation/wording issues introduced alongside the refactor (including misleading docs and minor grammar in public docs) that should be corrected before approval.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR is a follow-up to #2440 that renames the “no_connection_pooling” constructor to better reflect its actual semantics and applies the same “short-lived pooling for periodic traffic” behavior across libdd-http-client and libdd-agent-client, along with updating call sites and tests throughout the workspace.

Changes:

  • Renamed new_without_connection_poolingnew_periodic across the HttpClientCapability trait, implementations, and workspace call sites.
  • Added/propagated a periodic-client configuration in libdd-http-client that uses a small connection pool idle timeout instead of disabling pooling.
  • Updated libdd-agent-client to expose/forward the new periodic setting and default behavior.
File summaries
File Description
libdd-tracer-flare/src/lib.rs Switches tracer flare capabilities to new_periodic().
libdd-telemetry/src/worker/mod.rs Uses new_periodic() capabilities for telemetry worker client construction.
libdd-remote-config/src/fetch/shared.rs Updates remote-config tests to use new_periodic().
libdd-remote-config/src/fetch/multitarget.rs Updates multitarget fetcher tests to use new_periodic().
libdd-remote-config/src/fetch/fetcher.rs Updates fetcher tests to use new_periodic().
libdd-remote-config/src/fetch/agentless/integration_tests.rs Renames mock capability constructor to new_periodic().
libdd-remote-config/src/fetch/agentless.rs Updates agentless fetcher test wiring to use new_periodic().
libdd-remote-config/examples/remote_config_fetch.rs Updates example to use new_periodic().
libdd-remote-config/examples/remote_config_agentless_bench.rs Updates bench example to use new_periodic().
libdd-http-client/src/config.rs Replaces allow_connection_pooling with periodic config + adds periodic idle-timeout constant and tests.
libdd-http-client/src/backend/reqwest_backend.rs Applies small pool idle timeout when periodic() is enabled.
libdd-http-client/src/backend/hyper_backend.rs Applies small pool idle timeout (and timer) when periodic() is enabled.
libdd-http-client/Cargo.toml Enables hyper-util’s tokio feature needed for TokioTimer.
libdd-ffe/src/telemetry/flagevaluation/sender.rs Updates mock capability constructor to new_periodic().
libdd-data-pipeline/tests/common/mock_http.rs Updates mock capability constructor to new_periodic().
libdd-data-pipeline/src/trace_exporter/mod.rs Updates test capability wrapper to construct periodic capabilities.
libdd-data-pipeline-core/src/agentless/exporter.rs Updates mock capability constructor to new_periodic().
libdd-capabilities/src/http.rs Renames trait constructor to new_periodic().
libdd-capabilities-impl/src/lib.rs Updates native capabilities to delegate to NativeHttpClient::new_periodic().
libdd-capabilities-impl/src/http.rs Renames/rewires native HTTP client periodic flag and constructor.
libdd-agent-client/src/builder.rs Replaces pooling toggle with periodic toggle and forwards it to libdd-http-client.
datadog-sidecar/src/shm_remote_config.rs Switches sidecar remote-config fetcher capabilities to new_periodic().
datadog-sidecar/src/service/ffe_metrics_flusher.rs Updates mock capability constructor to new_periodic().
datadog-sidecar/src/service/ffe_exposures_flusher.rs Updates mock capability constructor to new_periodic().
datadog-live-debugger/src/sender.rs Updates mock capability constructor to new_periodic().
Review details
  • Files reviewed: 25/25 changed files
  • Comments generated: 3
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread libdd-agent-client/src/builder.rs Outdated
Comment thread libdd-capabilities/src/http.rs
Comment thread libdd-http-client/src/config.rs
yannham and others added 3 commits September 3, 2026 14:40
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Comment on lines +191 to +192
/// streams). Set to `false` only for high-frequency continuous senders (e.g. a streaming
/// profiling exporter).

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.

Do we still need a non-peridodic case ? Since we are mostly talking to the agent, we are always limited by the agent keep-alive so all client should use the agent timeout.

@yannham yannham Sep 4, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It's a good question. I think I added that to keep some compatibility with existing API/behavior in dd-trace-py (though the agent client isn't integrated yet). Note that it's set to true by default, so it's just an additional knob, but maybe it's useless... If I can't find a good reason in the next 30min or so I will get rid of it as part of this PR 🙂

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