Skip to content

refactor(statsd)!: make client clonable#2222

Open
VianneyRuhlmann wants to merge 1 commit into
mainfrom
vianney/statsd-client-refactor
Open

refactor(statsd)!: make client clonable#2222
VianneyRuhlmann wants to merge 1 commit into
mainfrom
vianney/statsd-client-refactor

Conversation

@VianneyRuhlmann

@VianneyRuhlmann VianneyRuhlmann commented Jul 10, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Refactor of the dogstatsd client crate.

Main changes are:

  • Separated code in 3 modules, action client and client/sink
  • Renamed Client to DogStatDClient to avoid renames when importing in other crates
  • Move new, create_client and do_send to be method of the DogStatsDClient
  • Replaced Mutex in DogStatsDClient to use a OnceLock and make the client handle clonable

Motivation

I've encountered several issues with the current design when sharing the client with the StatsExporter in #2159 and when adding the SharedRuntime backed client #2224 .

Additional Notes

Anything else we should know when reviewing?

How to test the change?

Describe here in detail how the change can be validated.

VianneyRuhlmann commented Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

@github-actions

Copy link
Copy Markdown
Contributor

Clippy Allow Annotation Report

Comparing clippy allow annotations between branches:

  • Base Branch: origin/main
  • PR Branch: origin/vianney/statsd-client-refactor

Summary by Rule

Rule Base Branch PR Branch Change
expect_used 2 2 No change (0%)
unwrap_used 9 9 No change (0%)
Total 11 11 No change (0%)

Annotation Counts by File

File Base Branch PR Branch Change
datadog-sidecar/src/service/session_info.rs 1 1 No change (0%)
datadog-sidecar/src/service/sidecar_server.rs 6 6 No change (0%)
libdd-data-pipeline/src/trace_exporter/mod.rs 2 2 No change (0%)
libdd-dogstatsd-client/src/client/mod.rs 0 1 ⚠️ +1 (N/A)
libdd-dogstatsd-client/src/lib.rs 1 0 ✅ -1 (-100.0%)
libdd-trace-stats/src/stats_exporter.rs 1 1 No change (0%)

Annotation Stats by Crate

Crate Base Branch PR Branch Change
clippy-annotation-reporter 5 5 No change (0%)
datadog-ffe-ffi 1 1 No change (0%)
datadog-ipc 22 22 No change (0%)
datadog-live-debugger 4 4 No change (0%)
datadog-live-debugger-ffi 10 10 No change (0%)
datadog-profiling-replayer 4 4 No change (0%)
datadog-sidecar 45 45 No change (0%)
libdd-common 13 13 No change (0%)
libdd-common-ffi 12 12 No change (0%)
libdd-data-pipeline 6 6 No change (0%)
libdd-ddsketch 2 2 No change (0%)
libdd-dogstatsd-client 1 1 No change (0%)
libdd-profiling 13 13 No change (0%)
libdd-remote-config 3 3 No change (0%)
libdd-telemetry 20 20 No change (0%)
libdd-tinybytes 4 4 No change (0%)
libdd-trace-normalization 2 2 No change (0%)
libdd-trace-obfuscation 3 3 No change (0%)
libdd-trace-stats 1 1 No change (0%)
libdd-trace-utils 11 11 No change (0%)
Total 182 182 No change (0%)

About This Report

This report tracks Clippy allow annotations for specific rules, showing how they've changed in this PR. Decreasing the number of these annotations generally improves code quality.

@github-actions

github-actions Bot commented Jul 10, 2026

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 5034 documentation warning(s) found

📦 datadog-sidecar - 2797 warning(s)

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

📦 libdd-dogstatsd-client - 169 warning(s)

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


Updated: 2026-07-10 14:13:45 UTC | Commit: 5ec69c1 | missing-docs job results

@github-actions

github-actions Bot commented Jul 10, 2026

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

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

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

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

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

advisories FAILED, bans ok, sources ok

📦 libdd-data-pipeline - 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:75:1
   │
75 │ 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.1.0
                     │   ├── libdd-capabilities-impl v3.0.0
                     │   │   ├── libdd-data-pipeline v7.0.0
                     │   │   ├── libdd-shared-runtime v2.0.0
                     │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   │   │   ├── libdd-telemetry v6.0.0
                     │   │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v6.0.0
                     │   │   │   │       └── libdd-data-pipeline v7.0.0 (*)
                     │   │   │   └── libdd-trace-stats v6.0.0 (*)
                     │   │   ├── libdd-trace-stats v6.0.0 (*)
                     │   │   └── libdd-trace-utils v9.0.0
                     │   │       ├── libdd-data-pipeline v7.0.0 (*)
                     │   │       ├── libdd-trace-obfuscation v5.0.0
                     │   │       │   └── libdd-trace-stats v6.0.0 (*)
                     │   │       ├── libdd-trace-stats v6.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
                     │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   ├── libdd-dogstatsd-client v4.0.0
                     │   │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   │   └── libdd-trace-stats v6.0.0 (*)
                     │   ├── libdd-shared-runtime v2.0.0 (*)
                     │   ├── libdd-telemetry v6.0.0 (*)
                     │   ├── libdd-trace-obfuscation v5.0.0 (*)
                     │   ├── libdd-trace-stats v6.0.0 (*)
                     │   └── libdd-trace-utils v9.0.0 (*)
                     ├── (dev) libdd-data-pipeline v7.0.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.0
                     │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   ├── libdd-telemetry v6.0.0 (*)
                     │   └── libdd-trace-stats v6.0.0 (*)
                     ├── (dev) libdd-trace-normalization v3.0.0
                     │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   └── libdd-trace-utils v9.0.0 (*)
                     ├── (dev) libdd-trace-obfuscation v5.0.0 (*)
                     ├── (dev) libdd-trace-stats v6.0.0 (*)
                     └── (dev) libdd-trace-utils v9.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:218:1
    │
218 │ 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) 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.1.0
      │   ├── libdd-capabilities-impl v3.0.0
      │   │   ├── libdd-data-pipeline v7.0.0
      │   │   ├── libdd-shared-runtime v2.0.0
      │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   │   ├── libdd-telemetry v6.0.0
      │   │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v6.0.0
      │   │   │   │       └── libdd-data-pipeline v7.0.0 (*)
      │   │   │   └── libdd-trace-stats v6.0.0 (*)
      │   │   ├── libdd-trace-stats v6.0.0 (*)
      │   │   └── libdd-trace-utils v9.0.0
      │   │       ├── libdd-data-pipeline v7.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v5.0.0
      │   │       │   └── libdd-trace-stats v6.0.0 (*)
      │   │       ├── libdd-trace-stats v6.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   ├── libdd-dogstatsd-client v4.0.0
      │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   └── libdd-trace-stats v6.0.0 (*)
      │   ├── libdd-shared-runtime v2.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   ├── libdd-trace-obfuscation v5.0.0 (*)
      │   ├── libdd-trace-stats v6.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-data-pipeline v7.0.0 (*)
      ├── (dev) libdd-ddsketch v1.1.0
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   └── libdd-trace-stats v6.0.0 (*)
      ├── (dev) libdd-trace-normalization v3.0.0
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-trace-stats v6.0.0 (*)
      ├── libdd-trace-utils v9.0.0 (*)
      └── proptest v1.5.0
          └── (dev) libdd-tinybytes v1.1.1
              ├── libdd-data-pipeline v7.0.0 (*)
              ├── (dev) libdd-tinybytes v1.1.1 (*)
              └── libdd-trace-utils v9.0.0 (*)

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

advisories FAILED, bans ok, sources ok

📦 libdd-dogstatsd-client - 1 error(s)

Show output
error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:71:1
   │
71 │ 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) 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.1.0
         └── libdd-dogstatsd-client v4.0.0

advisories FAILED, bans ok, sources ok

📦 libdd-trace-stats - 2 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:66:1
   │
66 │ 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.1.0
                     │   ├── libdd-capabilities-impl v3.0.0
                     │   │   ├── libdd-shared-runtime v2.0.0
                     │   │   │   ├── libdd-telemetry v6.0.0
                     │   │   │   │   └── libdd-trace-stats v6.0.0
                     │   │   │   └── libdd-trace-stats v6.0.0 (*)
                     │   │   ├── libdd-trace-stats v6.0.0 (*)
                     │   │   └── libdd-trace-utils v9.0.0
                     │   │       ├── libdd-trace-obfuscation v5.0.0
                     │   │       │   └── libdd-trace-stats v6.0.0 (*)
                     │   │       ├── libdd-trace-stats v6.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
                     │   ├── libdd-dogstatsd-client v4.0.0
                     │   │   └── libdd-trace-stats v6.0.0 (*)
                     │   ├── libdd-shared-runtime v2.0.0 (*)
                     │   ├── libdd-telemetry v6.0.0 (*)
                     │   ├── libdd-trace-obfuscation v5.0.0 (*)
                     │   ├── libdd-trace-stats v6.0.0 (*)
                     │   └── libdd-trace-utils v9.0.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.0
                     │   ├── libdd-telemetry v6.0.0 (*)
                     │   └── libdd-trace-stats v6.0.0 (*)
                     ├── (dev) libdd-trace-normalization v3.0.0
                     │   └── libdd-trace-utils v9.0.0 (*)
                     ├── (dev) libdd-trace-obfuscation v5.0.0 (*)
                     ├── (dev) libdd-trace-stats v6.0.0 (*)
                     └── (dev) libdd-trace-utils v9.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:198:1
    │
198 │ 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) 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.1.0
      │   ├── libdd-capabilities-impl v3.0.0
      │   │   ├── libdd-shared-runtime v2.0.0
      │   │   │   ├── libdd-telemetry v6.0.0
      │   │   │   │   └── libdd-trace-stats v6.0.0
      │   │   │   └── libdd-trace-stats v6.0.0 (*)
      │   │   ├── libdd-trace-stats v6.0.0 (*)
      │   │   └── libdd-trace-utils v9.0.0
      │   │       ├── libdd-trace-obfuscation v5.0.0
      │   │       │   └── libdd-trace-stats v6.0.0 (*)
      │   │       ├── libdd-trace-stats v6.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
      │   ├── libdd-dogstatsd-client v4.0.0
      │   │   └── libdd-trace-stats v6.0.0 (*)
      │   ├── libdd-shared-runtime v2.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   ├── libdd-trace-obfuscation v5.0.0 (*)
      │   ├── libdd-trace-stats v6.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-ddsketch v1.1.0
      │   ├── libdd-telemetry v6.0.0 (*)
      │   └── libdd-trace-stats v6.0.0 (*)
      ├── (dev) libdd-trace-normalization v3.0.0
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-trace-stats v6.0.0 (*)
      ├── libdd-trace-utils v9.0.0 (*)
      └── proptest v1.5.0
          └── (dev) libdd-tinybytes v1.1.1
              ├── (dev) libdd-tinybytes v1.1.1 (*)
              └── libdd-trace-utils v9.0.0 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-07-10 14:13:41 UTC | Commit: 5ec69c1 | dependency-check job results

@datadog-datadog-prod-us1

datadog-datadog-prod-us1 Bot commented Jul 10, 2026

Copy link
Copy Markdown
Contributor

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
Patch Coverage: 81.90%
Overall Coverage: 74.29% (-0.03%)

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 30d94f8 | Docs | Datadog PR Page | Give us feedback!

@pr-commenter

pr-commenter Bot commented Jul 10, 2026

Copy link
Copy Markdown

Benchmarks

Comparison

Benchmark execution time: 2026-07-10 14:22:24

Comparing candidate commit 30d94f8 in PR branch vianney/statsd-client-refactor with baseline commit a41a0f4 in branch main.

Found 2 performance improvements and 0 performance regressions! Performance is the same for 22 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:trace_buffer/4_senders/no_delay

  • 🟩 execution_time [-131.072µs; -98.678µs] or [-5.461%; -4.111%]
  • 🟩 throughput [+64850.025op/s; +86335.259op/s] or [+4.319%; +5.749%]

Benchmark execution time: 2026-07-10 14:18:38

Comparing candidate commit 30d94f8 in PR branch vianney/statsd-client-refactor with baseline commit a41a0f4 in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 3 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 ----------------------------------'

Candidate

Candidate benchmark details

Group 1

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 30d94f8 1783692681 vianney/statsd-client-refactor
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
trace_buffer/1_senders/10us_delay execution_time 56.324ms 56.576ms ± 0.144ms 56.548ms ± 0.074ms 56.639ms 56.821ms 57.012ms 57.353ms 1.42% 1.403 4.041 0.25% 0.010ms 1 200
trace_buffer/1_senders/10us_delay throughput 15692.283op/s 15908.048op/s ± 40.484op/s 15915.551op/s ± 20.800op/s 15935.857op/s 15959.930op/s 15970.641op/s 15979.089op/s 0.40% -1.372 3.872 0.25% 2.863op/s 1 200
trace_buffer/1_senders/1us_delay execution_time 50.025ms 50.083ms ± 0.034ms 50.081ms ± 0.012ms 50.090ms 50.150ms 50.199ms 50.210ms 0.26% 1.252 2.536 0.07% 0.002ms 1 200
trace_buffer/1_senders/1us_delay throughput 17924.723op/s 17970.246op/s ± 12.346op/s 17970.935op/s ± 4.126op/s 17976.264op/s 17988.953op/s 17990.272op/s 17991.156op/s 0.11% -1.246 2.520 0.07% 0.873op/s 1 200
trace_buffer/1_senders/no_delay execution_time 331.221µs 342.410µs ± 5.038µs 342.098µs ± 1.912µs 344.023µs 347.752µs 354.139µs 392.657µs 14.78% 5.062 48.217 1.47% 0.356µs 1 200
trace_buffer/1_senders/no_delay throughput 2292076.953op/s 2628953.887op/s ± 36257.313op/s 2630823.874op/s ± 14707.459op/s 2644876.402op/s 2672401.330op/s 2697644.312op/s 2717222.255op/s 3.28% -4.078 36.203 1.38% 2563.779op/s 1 200
trace_buffer/2_senders/10us_delay execution_time 56.738ms 57.097ms ± 0.173ms 57.086ms ± 0.122ms 57.217ms 57.390ms 57.492ms 57.711ms 1.10% 0.387 0.155 0.30% 0.012ms 1 200
trace_buffer/2_senders/10us_delay throughput 31189.639op/s 31525.762op/s ± 95.284op/s 31531.241op/s ± 67.287op/s 31594.218op/s 31673.349op/s 31717.936op/s 31724.782op/s 0.61% -0.369 0.125 0.30% 6.738op/s 1 200
trace_buffer/2_senders/1us_delay execution_time 50.036ms 50.112ms ± 0.041ms 50.102ms ± 0.020ms 50.126ms 50.201ms 50.246ms 50.276ms 0.35% 1.547 2.598 0.08% 0.003ms 1 200
trace_buffer/2_senders/1us_delay throughput 35802.350op/s 35919.711op/s ± 29.672op/s 35926.758op/s ± 14.603op/s 35940.894op/s 35950.358op/s 35953.857op/s 35974.335op/s 0.13% -1.541 2.576 0.08% 2.098op/s 1 200
trace_buffer/2_senders/no_delay execution_time 844.483µs 909.888µs ± 19.021µs 910.582µs ± 9.212µs 919.820µs 933.048µs 953.321µs 1029.411µs 13.05% 0.992 8.055 2.09% 1.345µs 1 200
trace_buffer/2_senders/no_delay throughput 1748573.011op/s 1979111.275op/s ± 40752.793op/s 1976757.908op/s ± 20045.844op/s 1996562.488op/s 2049956.763op/s 2074289.718op/s 2131482.610op/s 7.83% -0.484 5.647 2.05% 2881.658op/s 1 200
trace_buffer/4_senders/10us_delay execution_time 57.114ms 57.396ms ± 0.118ms 57.394ms ± 0.083ms 57.477ms 57.580ms 57.631ms 57.797ms 0.70% 0.220 0.301 0.20% 0.008ms 1 200
trace_buffer/4_senders/10us_delay throughput 62287.282op/s 62722.448op/s ± 128.393op/s 62723.944op/s ± 90.650op/s 62813.315op/s 62928.306op/s 62990.922op/s 63031.309op/s 0.49% -0.206 0.283 0.20% 9.079op/s 1 200
trace_buffer/4_senders/1us_delay execution_time 50.066ms 50.166ms ± 0.040ms 50.160ms ± 0.019ms 50.178ms 50.252ms 50.296ms 50.394ms 0.47% 1.903 6.294 0.08% 0.003ms 1 200
trace_buffer/4_senders/1us_delay throughput 71436.743op/s 71761.430op/s ± 56.697op/s 71770.932op/s ± 26.628op/s 71797.037op/s 71823.646op/s 71836.563op/s 71905.068op/s 0.19% -1.892 6.228 0.08% 4.009op/s 1 200
trace_buffer/4_senders/no_delay execution_time 2.085ms 2.285ms ± 0.082ms 2.284ms ± 0.054ms 2.338ms 2.416ms 2.502ms 2.521ms 10.36% 0.142 -0.083 3.59% 0.006ms 1 200
trace_buffer/4_senders/no_delay throughput 1428173.155op/s 1577246.843op/s ± 56641.869op/s 1576156.185op/s ± 36113.964op/s 1611573.479op/s 1676682.841op/s 1691924.121op/s 1726458.583op/s 9.54% 0.059 -0.153 3.58% 4005.185op/s 1 200
trace_buffer/8_senders/10us_delay execution_time 57.560ms 57.930ms ± 0.225ms 57.845ms ± 0.119ms 58.073ms 58.359ms 58.492ms 58.559ms 1.23% 0.880 -0.162 0.39% 0.016ms 1 200
trace_buffer/8_senders/10us_delay throughput 122953.789op/s 124290.000op/s ± 480.181op/s 124470.810op/s ± 256.204op/s 124664.026op/s 124836.740op/s 124935.500op/s 125086.438op/s 0.49% -0.868 -0.189 0.39% 33.954op/s 1 200
trace_buffer/8_senders/1us_delay execution_time 50.210ms 50.291ms ± 0.055ms 50.276ms ± 0.027ms 50.319ms 50.371ms 50.488ms 50.578ms 0.60% 1.795 5.407 0.11% 0.004ms 1 200
trace_buffer/8_senders/1us_delay throughput 142354.721op/s 143168.355op/s ± 156.214op/s 143210.156op/s ± 76.046op/s 143265.527op/s 143364.432op/s 143382.201op/s 143396.953op/s 0.13% -1.782 5.329 0.11% 11.046op/s 1 200
trace_buffer/8_senders/no_delay execution_time 6.127ms 6.480ms ± 0.073ms 6.480ms ± 0.044ms 6.523ms 6.598ms 6.642ms 6.651ms 2.63% -0.418 1.953 1.12% 0.005ms 1 200
trace_buffer/8_senders/no_delay throughput 1082534.104op/s 1111270.721op/s ± 12561.005op/s 1111041.185op/s ± 7504.964op/s 1118681.011op/s 1132681.415op/s 1138590.047op/s 1175035.777op/s 5.76% 0.552 2.477 1.13% 888.197op/s 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
trace_buffer/1_senders/10us_delay execution_time [56.555ms; 56.596ms] or [-0.035%; +0.035%] None None None
trace_buffer/1_senders/10us_delay throughput [15902.437op/s; 15913.659op/s] or [-0.035%; +0.035%] None None None
trace_buffer/1_senders/1us_delay execution_time [50.078ms; 50.088ms] or [-0.010%; +0.010%] None None None
trace_buffer/1_senders/1us_delay throughput [17968.535op/s; 17971.957op/s] or [-0.010%; +0.010%] None None None
trace_buffer/1_senders/no_delay execution_time [341.712µs; 343.109µs] or [-0.204%; +0.204%] None None None
trace_buffer/1_senders/no_delay throughput [2623928.972op/s; 2633978.802op/s] or [-0.191%; +0.191%] None None None
trace_buffer/2_senders/10us_delay execution_time [57.073ms; 57.121ms] or [-0.042%; +0.042%] None None None
trace_buffer/2_senders/10us_delay throughput [31512.556op/s; 31538.967op/s] or [-0.042%; +0.042%] None None None
trace_buffer/2_senders/1us_delay execution_time [50.106ms; 50.118ms] or [-0.011%; +0.011%] None None None
trace_buffer/2_senders/1us_delay throughput [35915.599op/s; 35923.824op/s] or [-0.011%; +0.011%] None None None
trace_buffer/2_senders/no_delay execution_time [907.252µs; 912.524µs] or [-0.290%; +0.290%] None None None
trace_buffer/2_senders/no_delay throughput [1973463.330op/s; 1984759.221op/s] or [-0.285%; +0.285%] None None None
trace_buffer/4_senders/10us_delay execution_time [57.380ms; 57.412ms] or [-0.028%; +0.028%] None None None
trace_buffer/4_senders/10us_delay throughput [62704.654op/s; 62740.242op/s] or [-0.028%; +0.028%] None None None
trace_buffer/4_senders/1us_delay execution_time [50.161ms; 50.172ms] or [-0.011%; +0.011%] None None None
trace_buffer/4_senders/1us_delay throughput [71753.572op/s; 71769.287op/s] or [-0.011%; +0.011%] None None None
trace_buffer/4_senders/no_delay execution_time [2.274ms; 2.297ms] or [-0.498%; +0.498%] None None None
trace_buffer/4_senders/no_delay throughput [1569396.824op/s; 1585096.861op/s] or [-0.498%; +0.498%] None None None
trace_buffer/8_senders/10us_delay execution_time [57.899ms; 57.961ms] or [-0.054%; +0.054%] None None None
trace_buffer/8_senders/10us_delay throughput [124223.452op/s; 124356.549op/s] or [-0.054%; +0.054%] None None None
trace_buffer/8_senders/1us_delay execution_time [50.283ms; 50.298ms] or [-0.015%; +0.015%] None None None
trace_buffer/8_senders/1us_delay throughput [143146.705op/s; 143190.005op/s] or [-0.015%; +0.015%] None None None
trace_buffer/8_senders/no_delay execution_time [6.470ms; 6.490ms] or [-0.156%; +0.156%] None None None
trace_buffer/8_senders/no_delay throughput [1109529.886op/s; 1113011.555op/s] or [-0.157%; +0.157%] None None None

Group 1

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 30d94f8 1783692681 vianney/statsd-client-refactor
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
concentrator/add_spans_to_concentrator execution_time 8.450ms 8.474ms ± 0.016ms 8.470ms ± 0.010ms 8.483ms 8.508ms 8.521ms 8.529ms 0.70% 1.023 0.834 0.19% 0.001ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
concentrator/add_spans_to_concentrator execution_time [8.471ms; 8.476ms] or [-0.027%; +0.027%] None None None

Group 2

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 30d94f8 1783692681 vianney/statsd-client-refactor
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
write only interface execution_time 1.056µs 1.074µs ± 0.005µs 1.075µs ± 0.003µs 1.077µs 1.080µs 1.085µs 1.088µs 1.18% -0.412 0.426 0.48% 0.000µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
write only interface execution_time [1.073µs; 1.074µs] or [-0.067%; +0.067%] None None None

Group 3

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 30d94f8 1783692681 vianney/statsd-client-refactor
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
two way interface execution_time 15.310µs 15.729µs ± 0.210µs 15.699µs ± 0.105µs 15.826µs 16.165µs 16.384µs 16.483µs 4.99% 1.130 1.564 1.33% 0.015µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
two way interface execution_time [15.700µs; 15.758µs] or [-0.185%; +0.185%] None None None

Baseline

Baseline benchmark details

Group 1

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a41a0f4 1783685334 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
trace_buffer/1_senders/10us_delay execution_time 56.289ms 56.554ms ± 0.137ms 56.526ms ± 0.063ms 56.605ms 56.799ms 57.008ms 57.273ms 1.32% 1.654 4.775 0.24% 0.010ms 1 200
trace_buffer/1_senders/10us_delay throughput 15714.099op/s 15914.075op/s ± 38.265op/s 15921.895op/s ± 17.789op/s 15936.307op/s 15961.406op/s 15977.820op/s 15988.826op/s 0.42% -1.625 4.621 0.24% 2.706op/s 1 200
trace_buffer/1_senders/1us_delay execution_time 49.979ms 50.077ms ± 0.035ms 50.080ms ± 0.013ms 50.087ms 50.140ms 50.178ms 50.270ms 0.38% 1.238 4.830 0.07% 0.002ms 1 200
trace_buffer/1_senders/1us_delay throughput 17903.420op/s 17972.382op/s ± 12.428op/s 17971.108op/s ± 4.752op/s 17979.499op/s 17989.365op/s 17990.388op/s 18007.432op/s 0.20% -1.227 4.775 0.07% 0.879op/s 1 200
trace_buffer/1_senders/no_delay execution_time 334.032µs 340.966µs ± 3.994µs 340.470µs ± 1.919µs 342.316µs 347.125µs 354.051µs 372.142µs 9.30% 3.024 18.287 1.17% 0.282µs 1 200
trace_buffer/1_senders/no_delay throughput 2418433.674op/s 2639904.712op/s ± 29933.615op/s 2643404.228op/s ± 14902.943op/s 2659265.979op/s 2671072.563op/s 2682244.056op/s 2694350.569op/s 1.93% -2.666 14.764 1.13% 2116.626op/s 1 200
trace_buffer/2_senders/10us_delay execution_time 56.701ms 57.124ms ± 0.175ms 57.103ms ± 0.114ms 57.224ms 57.423ms 57.504ms 57.563ms 0.81% 0.210 -0.307 0.31% 0.012ms 1 200
trace_buffer/2_senders/10us_delay throughput 31270.018op/s 31510.599op/s ± 96.653op/s 31522.051op/s ± 62.537op/s 31571.533op/s 31671.998op/s 31711.210op/s 31745.295op/s 0.71% -0.195 -0.311 0.31% 6.834op/s 1 200
trace_buffer/2_senders/1us_delay execution_time 50.065ms 50.111ms ± 0.030ms 50.108ms ± 0.016ms 50.121ms 50.170ms 50.221ms 50.225ms 0.23% 1.348 2.447 0.06% 0.002ms 1 200
trace_buffer/2_senders/1us_delay throughput 35838.799op/s 35920.533op/s ± 21.732op/s 35922.088op/s ± 11.781op/s 35935.533op/s 35948.180op/s 35951.276op/s 35953.058op/s 0.09% -1.343 2.430 0.06% 1.537op/s 1 200
trace_buffer/2_senders/no_delay execution_time 864.057µs 914.040µs ± 17.520µs 914.234µs ± 8.828µs 923.070µs 937.473µs 950.707µs 1028.718µs 12.52% 1.146 8.370 1.91% 1.239µs 1 200
trace_buffer/2_senders/no_delay throughput 1749750.661op/s 1969986.759op/s ± 37116.090op/s 1968862.226op/s ± 18904.161op/s 1987760.507op/s 2027879.131op/s 2062440.638op/s 2083194.829op/s 5.81% -0.688 5.666 1.88% 2624.504op/s 1 200
trace_buffer/4_senders/10us_delay execution_time 57.033ms 57.423ms ± 0.165ms 57.376ms ± 0.091ms 57.527ms 57.701ms 57.890ms 57.947ms 0.99% 0.662 0.242 0.29% 0.012ms 1 200
trace_buffer/4_senders/10us_delay throughput 62126.193op/s 62693.616op/s ± 180.312op/s 62744.013op/s ± 99.751op/s 62822.398op/s 62926.660op/s 63020.083op/s 63121.248op/s 0.60% -0.647 0.216 0.29% 12.750op/s 1 200
trace_buffer/4_senders/1us_delay execution_time 50.111ms 50.165ms ± 0.034ms 50.158ms ± 0.018ms 50.179ms 50.237ms 50.271ms 50.281ms 0.25% 1.261 1.523 0.07% 0.002ms 1 200
trace_buffer/4_senders/1us_delay throughput 71597.832op/s 71763.103op/s ± 48.283op/s 71773.343op/s ± 25.446op/s 71796.764op/s 71819.071op/s 71832.715op/s 71840.435op/s 0.09% -1.257 1.512 0.07% 3.414op/s 1 200
trace_buffer/4_senders/no_delay execution_time 2.183ms 2.400ms ± 0.083ms 2.406ms ± 0.061ms 2.461ms 2.514ms 2.554ms 2.578ms 7.15% -0.431 -0.287 3.45% 0.006ms 1 200
trace_buffer/4_senders/no_delay throughput 1396479.166op/s 1501654.201op/s ± 52915.325op/s 1496357.805op/s ± 37784.508op/s 1537962.978op/s 1600470.365op/s 1639917.181op/s 1648730.507op/s 10.18% 0.593 -0.064 3.51% 3741.679op/s 1 200
trace_buffer/8_senders/10us_delay execution_time 57.655ms 57.944ms ± 0.208ms 57.858ms ± 0.115ms 58.102ms 58.336ms 58.434ms 58.516ms 1.14% 0.763 -0.474 0.36% 0.015ms 1 200
trace_buffer/8_senders/10us_delay throughput 123044.031op/s 124259.580op/s ± 444.066op/s 124441.739op/s ± 246.794op/s 124569.174op/s 124800.762op/s 124868.423op/s 124881.471op/s 0.35% -0.753 -0.494 0.36% 31.400op/s 1 200
trace_buffer/8_senders/1us_delay execution_time 50.207ms 50.282ms ± 0.054ms 50.270ms ± 0.025ms 50.299ms 50.373ms 50.492ms 50.607ms 0.67% 2.305 8.434 0.11% 0.004ms 1 200
trace_buffer/8_senders/1us_delay throughput 142272.147op/s 143193.098op/s ± 153.202op/s 143227.188op/s ± 71.361op/s 143284.553op/s 143364.738op/s 143397.957op/s 143407.686op/s 0.13% -2.289 8.317 0.11% 10.833op/s 1 200
trace_buffer/8_senders/no_delay execution_time 6.134ms 6.550ms ± 0.109ms 6.564ms ± 0.063ms 6.624ms 6.702ms 6.741ms 6.745ms 2.76% -0.974 1.576 1.66% 0.008ms 1 200
trace_buffer/8_senders/no_delay throughput 1067394.129op/s 1099561.666op/s ± 18590.383op/s 1096875.409op/s ± 10698.871op/s 1108680.668op/s 1132969.652op/s 1157773.548op/s 1173760.391op/s 7.01% 1.110 2.032 1.69% 1314.539op/s 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
trace_buffer/1_senders/10us_delay execution_time [56.535ms; 56.573ms] or [-0.033%; +0.033%] None None None
trace_buffer/1_senders/10us_delay throughput [15908.771op/s; 15919.378op/s] or [-0.033%; +0.033%] None None None
trace_buffer/1_senders/1us_delay execution_time [50.072ms; 50.082ms] or [-0.010%; +0.010%] None None None
trace_buffer/1_senders/1us_delay throughput [17970.659op/s; 17974.104op/s] or [-0.010%; +0.010%] None None None
trace_buffer/1_senders/no_delay execution_time [340.413µs; 341.520µs] or [-0.162%; +0.162%] None None None
trace_buffer/1_senders/no_delay throughput [2635756.201op/s; 2644053.224op/s] or [-0.157%; +0.157%] None None None
trace_buffer/2_senders/10us_delay execution_time [57.100ms; 57.148ms] or [-0.043%; +0.043%] None None None
trace_buffer/2_senders/10us_delay throughput [31497.204op/s; 31523.994op/s] or [-0.043%; +0.043%] None None None
trace_buffer/2_senders/1us_delay execution_time [50.106ms; 50.115ms] or [-0.008%; +0.008%] None None None
trace_buffer/2_senders/1us_delay throughput [35917.522op/s; 35923.545op/s] or [-0.008%; +0.008%] None None None
trace_buffer/2_senders/no_delay execution_time [911.612µs; 916.468µs] or [-0.266%; +0.266%] None None None
trace_buffer/2_senders/no_delay throughput [1964842.826op/s; 1975130.692op/s] or [-0.261%; +0.261%] None None None
trace_buffer/4_senders/10us_delay execution_time [57.400ms; 57.446ms] or [-0.040%; +0.040%] None None None
trace_buffer/4_senders/10us_delay throughput [62668.626op/s; 62718.605op/s] or [-0.040%; +0.040%] None None None
trace_buffer/4_senders/1us_delay execution_time [50.160ms; 50.170ms] or [-0.009%; +0.009%] None None None
trace_buffer/4_senders/1us_delay throughput [71756.411op/s; 71769.794op/s] or [-0.009%; +0.009%] None None None
trace_buffer/4_senders/no_delay execution_time [2.389ms; 2.412ms] or [-0.480%; +0.480%] None None None
trace_buffer/4_senders/no_delay throughput [1494320.646op/s; 1508987.756op/s] or [-0.488%; +0.488%] None None None
trace_buffer/8_senders/10us_delay execution_time [57.915ms; 57.973ms] or [-0.050%; +0.050%] None None None
trace_buffer/8_senders/10us_delay throughput [124198.037op/s; 124321.123op/s] or [-0.050%; +0.050%] None None None
trace_buffer/8_senders/1us_delay execution_time [50.274ms; 50.289ms] or [-0.015%; +0.015%] None None None
trace_buffer/8_senders/1us_delay throughput [143171.866op/s; 143214.331op/s] or [-0.015%; +0.015%] None None None
trace_buffer/8_senders/no_delay execution_time [6.535ms; 6.565ms] or [-0.230%; +0.230%] None None None
trace_buffer/8_senders/no_delay throughput [1096985.218op/s; 1102138.114op/s] or [-0.234%; +0.234%] None None None

Group 1

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a41a0f4 1783685334 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
concentrator/add_spans_to_concentrator execution_time 8.445ms 8.476ms ± 0.018ms 8.472ms ± 0.012ms 8.487ms 8.507ms 8.529ms 8.548ms 0.90% 1.124 1.642 0.21% 0.001ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
concentrator/add_spans_to_concentrator execution_time [8.474ms; 8.479ms] or [-0.030%; +0.030%] None None None

Group 2

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a41a0f4 1783685334 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
write only interface execution_time 1.067µs 1.078µs ± 0.004µs 1.079µs ± 0.001µs 1.080µs 1.083µs 1.086µs 1.089µs 0.93% -1.020 1.578 0.34% 0.000µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
write only interface execution_time [1.078µs; 1.079µs] or [-0.047%; +0.047%] None None None

Group 3

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a41a0f4 1783685334 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
two way interface execution_time 15.610µs 15.920µs ± 0.203µs 15.863µs ± 0.084µs 15.974µs 16.271µs 16.439µs 17.219µs 8.55% 2.581 11.431 1.27% 0.014µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
two way interface execution_time [15.892µs; 15.948µs] or [-0.177%; +0.177%] None None None

@dd-octo-sts

dd-octo-sts Bot commented Jul 10, 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 85.88 MB 85.87 MB -0% (-5.63 KB) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 7.88 MB 7.88 MB 0% (0 B) 👌
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 10.61 MB 10.61 MB -0% (-104 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 97.10 MB 97.10 MB +0% (+208 B) 👌
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 25.45 MB 25.45 MB --.02% (-5.50 KB) 💪
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 88.44 KB 88.44 KB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 184.55 MB 184.49 MB --.03% (-64.00 KB) 💪
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 946.77 MB 946.57 MB --.02% (-198.76 KB) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 8.32 MB 8.32 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 88.44 KB 88.44 KB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 24.62 MB 24.62 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 49.03 MB 49.03 MB +0% (+18 B) 👌
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 22.05 MB 22.05 MB --.01% (-4.00 KB) 💪
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 89.82 KB 89.82 KB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 188.76 MB 188.69 MB --.03% (-72.00 KB) 💪
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 935.45 MB 935.27 MB --.01% (-180.69 KB) 💪
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 6.43 MB 6.43 MB +0% (+512 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 89.82 KB 89.82 KB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 26.43 MB 26.43 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 46.66 MB 46.66 MB +0% (+582 B) 👌
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 76.58 MB 76.58 MB -0% (-1.85 KB) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 8.78 MB 8.78 MB 0% (0 B) 👌
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 92.10 MB 92.11 MB +0% (+1.84 KB) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 10.69 MB 10.69 MB +0% (+136 B) 👌

@VianneyRuhlmann VianneyRuhlmann changed the title refactor(statsd): wrap client in arc refactor(statsd): make client clonable Jul 10, 2026
@VianneyRuhlmann VianneyRuhlmann force-pushed the vianney/statsd-client-refactor branch from 597364e to b905f96 Compare July 10, 2026 14:05
@VianneyRuhlmann VianneyRuhlmann force-pushed the vianney/statsd-client-refactor branch from b905f96 to 30d94f8 Compare July 10, 2026 14:11
@VianneyRuhlmann VianneyRuhlmann marked this pull request as ready for review July 10, 2026 14:38
@VianneyRuhlmann VianneyRuhlmann requested review from a team as code owners July 10, 2026 14:38
@VianneyRuhlmann VianneyRuhlmann changed the title refactor(statsd): make client clonable refactor(statsd)!: make client clonable Jul 10, 2026

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 30d94f86f0

ℹ️ About Codex in GitHub

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

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

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

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

Comment thread libdd-dogstatsd-client/src/lib.rs
Comment thread libdd-trace-stats/src/stats_exporter.rs
Comment on lines +123 to +127
match self.inner.client.get() {
Some(client) => Ok(client),
None => {
let client = Self::create_client(&self.inner.endpoint)?;
Ok(self.inner.client.get_or_init(|| client))

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 Badge Serialize first client initialization

When the first metric is sent concurrently, every caller that observes None runs create_client before get_or_init; that construction does DNS/socket setup and creates a QueuingMetricSink worker, but all except the winner are immediately dropped. This regresses the old mutex-serialized initialization and can spawn many transient queue workers/socket binds during startup bursts, so the fallible construction should be protected by a single initialization path.

Useful? React with 👍 / 👎.

@Aaalibaba42 Aaalibaba42 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Mostly nits, I don't know dogstatsd enough to approve though, just looked at the code.

Comment on lines +21 to +34
/// A dogstatsd-client that flushes stats to a given endpoint.
///
/// This client can be cloned and shared between threads.
#[derive(Debug, Default, Clone)]
pub struct DogStatsDClient {
inner: Arc<InnerClient>,
}

/// Inner struct of [DogStatsDClient] to be wrapped in [Arc].
#[derive(Debug, Default)]
struct InnerClient {
client: OnceLock<StatsdClient>,
endpoint: Endpoint,
}

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.

nit: I understand why it's more legible this way but I think I'd have preferred a struct DogStatsDClient(Arc<InnerClient>) or even struct DogStatsDClient(Arc<(OnceLock<StatsdClient>, Endpoint)>), I feel like this Inner struct is just for language reasons and not sementic

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.

I agree with struct DogStatsDClient(Arc<InnerClient>) but I'd rather have a proper struct to held Client fields rather than a tuple which is less readable in methods

Comment thread libdd-dogstatsd-client/src/client/mod.rs
Comment on lines +123 to +129
match self.inner.client.get() {
Some(client) => Ok(client),
None => {
let client = Self::create_client(&self.inner.endpoint)?;
Ok(self.inner.client.get_or_init(|| client))
}
}

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.

nit: slightly more legible imho

Suggested change
match self.inner.client.get() {
Some(client) => Ok(client),
None => {
let client = Self::create_client(&self.inner.endpoint)?;
Ok(self.inner.client.get_or_init(|| client))
}
}
if let Some(client) = self.inner.client.get() {
return Ok(client);
}
let client = Self::create_client(&self.inner.endpoint)?;
Ok(self.inner.client.get_or_init(|| client))

Comment on lines +153 to +163
{
let mut tags_iter = tags.into_iter();
let mut tag_opt = tags_iter.next();
#[allow(clippy::unwrap_used)]
while tag_opt.is_some() {
builder = builder.with_tag_value(tag_opt.unwrap().as_ref());
tag_opt = tags_iter.next();
}
builder.try_send()?;
Ok(())
}

@Aaalibaba42 Aaalibaba42 Jul 10, 2026

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.

nit:

Suggested change
{
let mut tags_iter = tags.into_iter();
let mut tag_opt = tags_iter.next();
#[allow(clippy::unwrap_used)]
while tag_opt.is_some() {
builder = builder.with_tag_value(tag_opt.unwrap().as_ref());
tag_opt = tags_iter.next();
}
builder.try_send()?;
Ok(())
}
{
let mut tags_iter = tags.into_iter();
while let Some(tag) = tag_opt.next() {
builder = builder.with_tag_value(tog.as_ref());
}
builder.try_send()?;
Ok(())
}

or even just this since V is IntoIterator

Suggested change
{
let mut tags_iter = tags.into_iter();
let mut tag_opt = tags_iter.next();
#[allow(clippy::unwrap_used)]
while tag_opt.is_some() {
builder = builder.with_tag_value(tag_opt.unwrap().as_ref());
tag_opt = tags_iter.next();
}
builder.try_send()?;
Ok(())
}
{
for tag in tags {
builder = builder.with_tag_value(tag.as_ref());
}
builder.try_send()?;
Ok(())
}

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.

Good catch this code has some really weird designs

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.

2 participants