Skip to content

feat(telemetry)!: Add Installation signature and AppProduct changes payloads#2213

Open
bwoebi wants to merge 1 commit into
mainfrom
bob/py-telem
Open

feat(telemetry)!: Add Installation signature and AppProduct changes payloads#2213
bwoebi wants to merge 1 commit into
mainfrom
bob/py-telem

Conversation

@bwoebi

@bwoebi bwoebi commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

And some smaller stuff like more metric namespaces.

This bridges the gap to the current capabilities exposed by dd-trace-py.

@datadog-prod-us1-4

datadog-prod-us1-4 Bot commented Jul 8, 2026

Copy link
Copy Markdown

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
Patch Coverage: 66.22%
Overall Coverage: 74.39% (-0.04%)

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

Comment on lines +21 to +22
pub use libdd_common::tag::{parse_tags, Tag};
pub use libdd_common::{parse_uri, Endpoint};

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.

This is here. But we expose Tag currently publicly in data/metrics.rs. So we need that right now...

@github-actions

github-actions Bot commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 5576 documentation warning(s) found

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

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

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

📦 libdd-telemetry - 539 warning(s)


Updated: 2026-07-14 13:05:34 UTC | Commit: 1694e48 | missing-docs job results

@bwoebi bwoebi changed the title Add Installation signature and AppProduct changes payloads feat(telemetry)!: Add Installation signature and AppProduct changes payloads Jul 8, 2026
@github-actions

github-actions Bot commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

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

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

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

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:194:1
    │
194 │ 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-telemetry-ffi v37.0.0
      │   ├── libdd-common-ffi v37.0.0
      │   │   └── libdd-telemetry-ffi v37.0.0 (*)
      │   ├── libdd-shared-runtime v2.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   └── libdd-telemetry-ffi v37.0.0 (*)
      └── (dev) libdd-ddsketch v1.1.0
          └── libdd-telemetry v6.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-telemetry - 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:51:1
   │
51 │ 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) libdd-ddsketch v1.1.0
                         └── libdd-telemetry v6.0.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:163:1
    │
163 │ 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-shared-runtime v2.0.0 (*)
      │   └── libdd-telemetry v6.0.0 (*)
      └── (dev) libdd-ddsketch v1.1.0
          └── libdd-telemetry v6.0.0 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-07-14 13:05:23 UTC | Commit: 1694e48 | dependency-check job results

@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: 6f102bdf44

ℹ️ 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".

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

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

#[cfg(feature = "telemetry")]
telemetry: Option<TelemetryConfig>,
#[cfg(feature = "telemetry")]
telemetry_handle: Option<TelemetryWorkerHandle>,

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Badge Initialize the telemetry handle field in the builder

With the default telemetry feature enabled, this newly added field is never initialized by TraceExporterBuilder::new(), so constructing the builder fails to compile (cargo check -p libdd-data-pipeline reports E0063 at the Self { ... } initializer). Please add telemetry_handle: None under the same cfg gate in new() so the default data-pipeline build remains usable.

Useful? React with 👍 / 👎.

Telemetry,
Apm,
Sidecar,
Civisibility,

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 CI Visibility metrics under the expected namespace

Because this enum uses #[serde(rename_all = "snake_case")], the new Civisibility variant serializes as "civisibility" rather than the CI Visibility namespace name ("ci_visibility"). When callers register CI Visibility telemetry metrics with this variant, the payload will carry an unknown/misspelled namespace and those metrics can be rejected or misclassified; use a variant/serde rename that emits ci_visibility.

Useful? React with 👍 / 👎.

dependencies: self.data.dependencies.unflushed().cloned().collect(),
integrations: self.data.integrations.unflushed().cloned().collect(),
install_signature: self.data.install_signature.clone(),
products: self.data.products.clone(),

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 Clear pending product changes after app-started

When a product is registered before send_start, it is included in the initial app-started payload here, but app_started_sent_success() only clears dependencies/configurations/integrations and leaves the product name in products_pending. The next FlushData will therefore emit an app-product-change for the same initial state, double-reporting product enablement; clear the pending product entries after a successful AppStarted send as well.

Useful? React with 👍 / 👎.

Comment on lines +15 to +18
#[serde(skip_serializing_if = "Option::is_none")]
pub hash: Option<String>,
#[serde(skip_serializing_if = "Option::is_none")]
pub metadata: Option<Vec<DependencyMetadata>>,

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Badge Update all Dependency constructors for the new fields

Adding hash and metadata as required struct fields breaks existing in-tree constructors that still use Dependency { name, version } (for example datadog-sidecar-ffi/src/lib.rs:515), so after the data-pipeline initializer is fixed those crates will fail with E0063. Update those constructors to include the new fields, or use ..Default::default(), so the workspace continues to compile.

Useful? React with 👍 / 👎.

Comment on lines +531 to +539
if !self.data.products.is_empty() {
let products = self
.data
.products
.iter()
.map(|(name, state)| (name.clone(), state.clone()))
.collect();
let product_change =
data::Payload::AppProductChange(data::AppProductChange { products });

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 Gate extended-heartbeat product changes on pending state

Once any product has been recorded, every ExtendedHeartbeat takes this branch because it checks the full products map rather than products_pending, so long-running processes will emit app-product-change for unchanged product states on every extended heartbeat even after the pending set was cleared. Build this payload only from pending products, or omit it here and let the normal change batch handle product changes.

Useful? React with 👍 / 👎.

Comment on lines +17 to +18
#[serde(skip_serializing_if = "Option::is_none")]
pub metadata: Option<Vec<DependencyMetadata>>,

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 Keep dependency metadata out of the store identity

Because Store<Dependency> deduplicates by the derived Hash/Eq, including the new metadata field in that identity makes the same package/version a second stored dependency when SCA metadata is attached after the initial dependency report. On the next extended heartbeat, unflush_stored() will re-send both the stale entry and the updated metadata entry for the same dependency; track identity by the stable dependency key and update metadata in place instead.

Useful? React with 👍 / 👎.

@bwoebi bwoebi requested a review from a team as a code owner July 14, 2026 12:50
And some smaller stuff like more metric namespaces.
@pr-commenter

pr-commenter Bot commented Jul 14, 2026

Copy link
Copy Markdown

Benchmarks

Comparison

Benchmark execution time: 2026-07-14 13:15:53

Comparing candidate commit 5742b44 in PR branch bob/py-telem with baseline commit 56dab85 in branch main.

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

Benchmark execution time: 2026-07-14 13:13:40

Comparing candidate commit 5742b44 in PR branch bob/py-telem with baseline commit 56dab85 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 5742b44 1784034208 bob/py-telem
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.410ms 8.439ms ± 0.016ms 8.435ms ± 0.010ms 8.449ms 8.471ms 8.487ms 8.492ms 0.68% 0.874 0.385 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.437ms; 8.441ms] 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 5742b44 1784034208 bob/py-telem
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.335ms 56.592ms ± 0.134ms 56.580ms ± 0.086ms 56.665ms 56.847ms 57.025ms 57.069ms 0.86% 1.025 1.318 0.24% 0.009ms 1 200
trace_buffer/1_senders/10us_delay throughput 15770.300op/s 15903.354op/s ± 37.604op/s 15906.595op/s ± 24.257op/s 15930.849op/s 15954.008op/s 15962.783op/s 15975.869op/s 0.44% -1.009 1.272 0.24% 2.659op/s 1 200
trace_buffer/1_senders/1us_delay execution_time 49.962ms 50.083ms ± 0.028ms 50.079ms ± 0.011ms 50.088ms 50.141ms 50.181ms 50.189ms 0.22% 1.107 4.086 0.06% 0.002ms 1 200
trace_buffer/1_senders/1us_delay throughput 17932.055op/s 17970.286op/s ± 10.145op/s 17971.730op/s ± 3.852op/s 17975.608op/s 17980.584op/s 17986.156op/s 18013.801op/s 0.23% -1.099 4.087 0.06% 0.717op/s 1 200
trace_buffer/1_senders/no_delay execution_time 332.039µs 338.948µs ± 3.213µs 338.431µs ± 1.772µs 340.669µs 344.411µs 350.401µs 352.978µs 4.30% 1.321 3.462 0.95% 0.227µs 1 200
trace_buffer/1_senders/no_delay throughput 2549733.052op/s 2655505.871op/s ± 24871.204op/s 2659331.888op/s ± 13935.516op/s 2671937.158op/s 2687363.368op/s 2699350.525op/s 2710526.852op/s 1.93% -1.219 3.058 0.93% 1758.660op/s 1 200
trace_buffer/2_senders/10us_delay execution_time 56.829ms 57.246ms ± 0.199ms 57.238ms ± 0.152ms 57.387ms 57.610ms 57.707ms 57.830ms 1.03% 0.287 -0.254 0.35% 0.014ms 1 200
trace_buffer/2_senders/10us_delay throughput 31125.964op/s 31443.858op/s ± 109.174op/s 31447.743op/s ± 83.459op/s 31530.971op/s 31612.748op/s 31646.451op/s 31673.876op/s 0.72% -0.270 -0.275 0.35% 7.720op/s 1 200
trace_buffer/2_senders/1us_delay execution_time 50.053ms 50.121ms ± 0.043ms 50.109ms ± 0.018ms 50.138ms 50.199ms 50.247ms 50.389ms 0.56% 2.012 7.098 0.09% 0.003ms 1 200
trace_buffer/2_senders/1us_delay throughput 35722.294op/s 35912.760op/s ± 31.018op/s 35921.686op/s ± 12.923op/s 35931.606op/s 35946.642op/s 35949.489op/s 35962.010op/s 0.11% -1.999 6.999 0.09% 2.193op/s 1 200
trace_buffer/2_senders/no_delay execution_time 863.682µs 914.352µs ± 14.150µs 914.996µs ± 8.474µs 923.791µs 934.793µs 942.580µs 952.189µs 4.06% -0.672 1.114 1.54% 1.001µs 1 200
trace_buffer/2_senders/no_delay throughput 1890380.455op/s 1969081.145op/s ± 30822.849op/s 1967221.312op/s ± 18051.094op/s 1983684.137op/s 2025737.654op/s 2065728.022op/s 2084100.934op/s 5.94% 0.798 1.371 1.56% 2179.505op/s 1 200
trace_buffer/4_senders/10us_delay execution_time 57.087ms 57.459ms ± 0.148ms 57.449ms ± 0.094ms 57.531ms 57.739ms 57.884ms 57.913ms 0.81% 0.630 0.723 0.26% 0.010ms 1 200
trace_buffer/4_senders/10us_delay throughput 62162.283op/s 62653.895op/s ± 161.632op/s 62663.990op/s ± 102.437op/s 62768.727op/s 62880.843op/s 62981.493op/s 63061.129op/s 0.63% -0.612 0.697 0.26% 11.429op/s 1 200
trace_buffer/4_senders/1us_delay execution_time 50.079ms 50.168ms ± 0.035ms 50.161ms ± 0.015ms 50.178ms 50.249ms 50.280ms 50.319ms 0.32% 1.530 3.495 0.07% 0.002ms 1 200
trace_buffer/4_senders/1us_delay throughput 71543.599op/s 71758.637op/s ± 50.289op/s 71769.526op/s ± 21.269op/s 71787.889op/s 71818.142op/s 71831.295op/s 71886.302op/s 0.16% -1.524 3.471 0.07% 3.556op/s 1 200
trace_buffer/4_senders/no_delay execution_time 2.129ms 2.373ms ± 0.076ms 2.375ms ± 0.047ms 2.419ms 2.500ms 2.539ms 2.591ms 9.13% -0.075 0.280 3.19% 0.005ms 1 200
trace_buffer/4_senders/no_delay throughput 1389185.337op/s 1518753.275op/s ± 48861.768op/s 1515978.652op/s ± 30354.244op/s 1549458.917op/s 1600370.043op/s 1633372.247op/s 1690678.707op/s 11.52% 0.297 0.444 3.21% 3455.049op/s 1 200
trace_buffer/8_senders/10us_delay execution_time 57.610ms 57.910ms ± 0.207ms 57.832ms ± 0.110ms 58.025ms 58.321ms 58.484ms 58.655ms 1.42% 1.121 0.813 0.36% 0.015ms 1 200
trace_buffer/8_senders/10us_delay throughput 122752.627op/s 124332.462op/s ± 441.941op/s 124497.897op/s ± 237.180op/s 124667.360op/s 124819.675op/s 124874.321op/s 124979.179op/s 0.39% -1.104 0.758 0.35% 31.250op/s 1 200
trace_buffer/8_senders/1us_delay execution_time 50.210ms 50.300ms ± 0.065ms 50.281ms ± 0.035ms 50.336ms 50.402ms 50.524ms 50.572ms 0.58% 1.387 2.446 0.13% 0.005ms 1 200
trace_buffer/8_senders/1us_delay throughput 142371.867op/s 143141.224op/s ± 185.660op/s 143195.287op/s ± 101.091op/s 143262.665op/s 143361.183op/s 143390.359op/s 143398.649op/s 0.14% -1.378 2.406 0.13% 13.128op/s 1 200
trace_buffer/8_senders/no_delay execution_time 5.698ms 6.392ms ± 0.187ms 6.442ms ± 0.091ms 6.521ms 6.593ms 6.661ms 6.685ms 3.78% -1.390 1.954 2.91% 0.013ms 1 200
trace_buffer/8_senders/no_delay throughput 1076988.525op/s 1127474.330op/s ± 34432.477op/s 1117719.927op/s ± 15548.227op/s 1138925.065op/s 1198046.451op/s 1244493.859op/s 1263592.985op/s 13.05% 1.578 2.672 3.05% 2434.744op/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.574ms; 56.611ms] or [-0.033%; +0.033%] None None None
trace_buffer/1_senders/10us_delay throughput [15898.143op/s; 15908.566op/s] or [-0.033%; +0.033%] None None None
trace_buffer/1_senders/1us_delay execution_time [50.079ms; 50.087ms] or [-0.008%; +0.008%] None None None
trace_buffer/1_senders/1us_delay throughput [17968.880op/s; 17971.692op/s] or [-0.008%; +0.008%] None None None
trace_buffer/1_senders/no_delay execution_time [338.503µs; 339.394µs] or [-0.131%; +0.131%] None None None
trace_buffer/1_senders/no_delay throughput [2652058.962op/s; 2658952.781op/s] or [-0.130%; +0.130%] None None None
trace_buffer/2_senders/10us_delay execution_time [57.218ms; 57.273ms] or [-0.048%; +0.048%] None None None
trace_buffer/2_senders/10us_delay throughput [31428.727op/s; 31458.988op/s] or [-0.048%; +0.048%] None None None
trace_buffer/2_senders/1us_delay execution_time [50.115ms; 50.128ms] or [-0.012%; +0.012%] None None None
trace_buffer/2_senders/1us_delay throughput [35908.461op/s; 35917.059op/s] or [-0.012%; +0.012%] None None None
trace_buffer/2_senders/no_delay execution_time [912.391µs; 916.313µs] or [-0.214%; +0.214%] None None None
trace_buffer/2_senders/no_delay throughput [1964809.394op/s; 1973352.895op/s] or [-0.217%; +0.217%] None None None
trace_buffer/4_senders/10us_delay execution_time [57.438ms; 57.479ms] or [-0.036%; +0.036%] None None None
trace_buffer/4_senders/10us_delay throughput [62631.495op/s; 62676.296op/s] or [-0.036%; +0.036%] None None None
trace_buffer/4_senders/1us_delay execution_time [50.163ms; 50.173ms] or [-0.010%; +0.010%] None None None
trace_buffer/4_senders/1us_delay throughput [71751.667op/s; 71765.606op/s] or [-0.010%; +0.010%] None None None
trace_buffer/4_senders/no_delay execution_time [2.362ms; 2.383ms] or [-0.443%; +0.443%] None None None
trace_buffer/4_senders/no_delay throughput [1511981.504op/s; 1525525.046op/s] or [-0.446%; +0.446%] None None None
trace_buffer/8_senders/10us_delay execution_time [57.881ms; 57.939ms] or [-0.049%; +0.049%] None None None
trace_buffer/8_senders/10us_delay throughput [124271.213op/s; 124393.710op/s] or [-0.049%; +0.049%] None None None
trace_buffer/8_senders/1us_delay execution_time [50.291ms; 50.309ms] or [-0.018%; +0.018%] None None None
trace_buffer/8_senders/1us_delay throughput [143115.493op/s; 143166.954op/s] or [-0.018%; +0.018%] None None None
trace_buffer/8_senders/no_delay execution_time [6.366ms; 6.418ms] or [-0.405%; +0.405%] None None None
trace_buffer/8_senders/no_delay throughput [1122702.320op/s; 1132246.340op/s] or [-0.423%; +0.423%] None None None

Group 1

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 5742b44 1784034208 bob/py-telem
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.051µs 1.068µs ± 0.008µs 1.067µs ± 0.005µs 1.072µs 1.081µs 1.092µs 1.094µs 2.51% 0.771 1.172 0.73% 0.001µ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.067µs; 1.069µs] or [-0.101%; +0.101%] None None None

Group 2

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 5742b44 1784034208 bob/py-telem
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 14.827µs 15.316µs ± 0.217µs 15.282µs ± 0.101µs 15.394µs 15.606µs 15.924µs 16.840µs 10.19% 3.004 16.830 1.42% 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.286µs; 15.346µs] or [-0.197%; +0.197%] None None None

Group 3

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 5742b44 1784034208 bob/py-telem
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
receiver_entry_point/report/2644 execution_time 3.774ms 3.805ms ± 0.013ms 3.804ms ± 0.008ms 3.811ms 3.827ms 3.839ms 3.871ms 1.76% 0.914 2.773 0.34% 0.001ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
receiver_entry_point/report/2644 execution_time [3.803ms; 3.806ms] or [-0.048%; +0.048%] 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 56dab85 1784024118 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.397ms 8.430ms ± 0.017ms 8.427ms ± 0.011ms 8.441ms 8.460ms 8.482ms 8.518ms 1.08% 1.109 2.858 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.428ms; 8.433ms] or [-0.029%; +0.029%] None None None

Group 2

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 56dab85 1784024118 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.348ms 56.707ms ± 0.286ms 56.611ms ± 0.121ms 56.758ms 57.408ms 57.629ms 57.736ms 1.99% 1.753 2.666 0.50% 0.020ms 1 200
trace_buffer/1_senders/10us_delay throughput 15588.240op/s 15871.396op/s ± 79.443op/s 15897.941op/s ± 34.007op/s 15921.065op/s 15943.991op/s 15964.538op/s 15972.224op/s 0.47% -1.729 2.579 0.50% 5.617op/s 1 200
trace_buffer/1_senders/1us_delay execution_time 49.945ms 50.081ms ± 0.031ms 50.078ms ± 0.011ms 50.086ms 50.135ms 50.192ms 50.197ms 0.24% 1.048 4.620 0.06% 0.002ms 1 200
trace_buffer/1_senders/1us_delay throughput 17929.229op/s 17971.065op/s ± 11.240op/s 17971.951op/s ± 4.050op/s 17976.591op/s 17983.765op/s 17995.321op/s 18019.874op/s 0.27% -1.038 4.621 0.06% 0.795op/s 1 200
trace_buffer/1_senders/no_delay execution_time 332.743µs 341.772µs ± 5.935µs 341.413µs ± 2.207µs 343.520µs 347.024µs 355.861µs 407.334µs 19.31% 6.956 73.182 1.73% 0.420µs 1 200
trace_buffer/1_senders/no_delay throughput 2209488.733op/s 2634046.396op/s ± 41240.810op/s 2636101.784op/s ± 16932.931op/s 2653971.385op/s 2681889.933op/s 2693451.708op/s 2704792.750op/s 2.61% -5.680 55.022 1.56% 2916.166op/s 1 200
trace_buffer/2_senders/10us_delay execution_time 56.971ms 57.306ms ± 0.158ms 57.298ms ± 0.122ms 57.413ms 57.554ms 57.619ms 57.836ms 0.94% 0.173 -0.320 0.27% 0.011ms 1 200
trace_buffer/2_senders/10us_delay throughput 31122.394op/s 31410.540op/s ± 86.442op/s 31414.832op/s ± 66.542op/s 31484.104op/s 31541.592op/s 31580.688op/s 31595.084op/s 0.57% -0.160 -0.336 0.27% 6.112op/s 1 200
trace_buffer/2_senders/1us_delay execution_time 50.022ms 50.120ms ± 0.038ms 50.112ms ± 0.016ms 50.132ms 50.190ms 50.235ms 50.304ms 0.38% 1.521 4.341 0.08% 0.003ms 1 200
trace_buffer/2_senders/1us_delay throughput 35782.540op/s 35913.504op/s ± 27.353op/s 35919.588op/s ± 11.826op/s 35928.668op/s 35943.362op/s 35954.753op/s 35984.444op/s 0.18% -1.512 4.304 0.08% 1.934op/s 1 200
trace_buffer/2_senders/no_delay execution_time 841.363µs 891.172µs ± 17.297µs 892.919µs ± 12.842µs 904.759µs 917.040µs 922.879µs 933.678µs 4.56% -0.249 -0.348 1.94% 1.223µs 1 200
trace_buffer/2_senders/no_delay throughput 1927858.809op/s 2020574.320op/s ± 39443.709op/s 2015860.099op/s ± 28823.473op/s 2049024.337op/s 2087991.570op/s 2117872.883op/s 2139386.582op/s 6.13% 0.342 -0.269 1.95% 2789.091op/s 1 200
trace_buffer/4_senders/10us_delay execution_time 57.423ms 57.638ms ± 0.110ms 57.613ms ± 0.067ms 57.699ms 57.866ms 57.934ms 58.075ms 0.80% 0.945 0.878 0.19% 0.008ms 1 200
trace_buffer/4_senders/10us_delay throughput 61988.526op/s 62458.579op/s ± 119.265op/s 62485.581op/s ± 72.282op/s 62545.699op/s 62610.068op/s 62643.181op/s 62692.334op/s 0.33% -0.933 0.845 0.19% 8.433op/s 1 200
trace_buffer/4_senders/1us_delay execution_time 50.101ms 50.174ms ± 0.037ms 50.164ms ± 0.016ms 50.188ms 50.266ms 50.300ms 50.314ms 0.30% 1.561 2.873 0.07% 0.003ms 1 200
trace_buffer/4_senders/1us_delay throughput 71550.447op/s 71750.639op/s ± 52.492op/s 71764.041op/s ± 22.737op/s 71782.425op/s 71809.743op/s 71824.456op/s 71855.030op/s 0.13% -1.556 2.854 0.07% 3.712op/s 1 200
trace_buffer/4_senders/no_delay execution_time 2.288ms 2.468ms ± 0.056ms 2.478ms ± 0.035ms 2.509ms 2.539ms 2.569ms 2.574ms 3.85% -0.785 0.334 2.26% 0.004ms 1 200
trace_buffer/4_senders/no_delay throughput 1398856.901op/s 1459165.695op/s ± 33660.418op/s 1452647.300op/s ± 20701.036op/s 1479948.399op/s 1522917.732op/s 1551459.018op/s 1573434.924op/s 8.32% 0.905 0.609 2.30% 2380.151op/s 1 200
trace_buffer/8_senders/10us_delay execution_time 57.663ms 58.012ms ± 0.261ms 57.899ms ± 0.135ms 58.195ms 58.514ms 58.690ms 58.789ms 1.54% 0.873 -0.349 0.45% 0.018ms 1 200
trace_buffer/8_senders/10us_delay throughput 122471.154op/s 124113.882op/s ± 557.287op/s 124355.058op/s ± 291.708op/s 124540.676op/s 124730.117op/s 124806.654op/s 124862.352op/s 0.41% -0.861 -0.378 0.45% 39.406op/s 1 200
trace_buffer/8_senders/1us_delay execution_time 50.207ms 50.290ms ± 0.047ms 50.280ms ± 0.024ms 50.311ms 50.371ms 50.441ms 50.500ms 0.44% 1.495 3.114 0.09% 0.003ms 1 200
trace_buffer/8_senders/1us_delay throughput 142573.746op/s 143170.470op/s ± 134.589op/s 143198.558op/s ± 68.361op/s 143258.735op/s 143323.397op/s 143380.110op/s 143406.395op/s 0.15% -1.487 3.080 0.09% 9.517op/s 1 200
trace_buffer/8_senders/no_delay execution_time 6.430ms 6.654ms ± 0.096ms 6.664ms ± 0.052ms 6.707ms 6.768ms 6.810ms 7.404ms 11.10% 2.015 17.026 1.44% 0.007ms 1 200
trace_buffer/8_senders/no_delay throughput 972462.036op/s 1082197.726op/s ± 15268.742op/s 1080429.255op/s ± 8483.167op/s 1090892.521op/s 1107452.382op/s 1114417.316op/s 1119665.784op/s 3.63% -1.439 12.135 1.41% 1079.663op/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.668ms; 56.747ms] or [-0.070%; +0.070%] None None None
trace_buffer/1_senders/10us_delay throughput [15860.386op/s; 15882.406op/s] or [-0.069%; +0.069%] None None None
trace_buffer/1_senders/1us_delay execution_time [50.076ms; 50.085ms] or [-0.009%; +0.009%] None None None
trace_buffer/1_senders/1us_delay throughput [17969.508op/s; 17972.623op/s] or [-0.009%; +0.009%] None None None
trace_buffer/1_senders/no_delay execution_time [340.949µs; 342.594µs] or [-0.241%; +0.241%] None None None
trace_buffer/1_senders/no_delay throughput [2628330.816op/s; 2639761.975op/s] or [-0.217%; +0.217%] None None None
trace_buffer/2_senders/10us_delay execution_time [57.284ms; 57.328ms] or [-0.038%; +0.038%] None None None
trace_buffer/2_senders/10us_delay throughput [31398.559op/s; 31422.520op/s] or [-0.038%; +0.038%] None None None
trace_buffer/2_senders/1us_delay execution_time [50.115ms; 50.126ms] or [-0.011%; +0.011%] None None None
trace_buffer/2_senders/1us_delay throughput [35909.713op/s; 35917.295op/s] or [-0.011%; +0.011%] None None None
trace_buffer/2_senders/no_delay execution_time [888.774µs; 893.569µs] or [-0.269%; +0.269%] None None None
trace_buffer/2_senders/no_delay throughput [2015107.801op/s; 2026040.839op/s] or [-0.271%; +0.271%] None None None
trace_buffer/4_senders/10us_delay execution_time [57.623ms; 57.654ms] or [-0.027%; +0.027%] None None None
trace_buffer/4_senders/10us_delay throughput [62442.050op/s; 62475.108op/s] or [-0.026%; +0.026%] None None None
trace_buffer/4_senders/1us_delay execution_time [50.169ms; 50.179ms] or [-0.010%; +0.010%] None None None
trace_buffer/4_senders/1us_delay throughput [71743.364op/s; 71757.913op/s] or [-0.010%; +0.010%] None None None
trace_buffer/4_senders/no_delay execution_time [2.461ms; 2.476ms] or [-0.314%; +0.314%] None None None
trace_buffer/4_senders/no_delay throughput [1454500.685op/s; 1463830.705op/s] or [-0.320%; +0.320%] None None None
trace_buffer/8_senders/10us_delay execution_time [57.976ms; 58.049ms] or [-0.062%; +0.062%] None None None
trace_buffer/8_senders/10us_delay throughput [124036.648op/s; 124191.117op/s] or [-0.062%; +0.062%] None None None
trace_buffer/8_senders/1us_delay execution_time [50.283ms; 50.296ms] or [-0.013%; +0.013%] None None None
trace_buffer/8_senders/1us_delay throughput [143151.818op/s; 143189.123op/s] or [-0.013%; +0.013%] None None None
trace_buffer/8_senders/no_delay execution_time [6.641ms; 6.668ms] or [-0.200%; +0.200%] None None None
trace_buffer/8_senders/no_delay throughput [1080081.625op/s; 1084313.827op/s] or [-0.196%; +0.196%] None None None

Group 1

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 56dab85 1784024118 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.051µs 1.081µs ± 0.010µs 1.081µs ± 0.007µs 1.088µs 1.095µs 1.098µs 1.101µs 1.88% -0.272 -0.329 0.91% 0.001µ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.079µs; 1.082µs] or [-0.127%; +0.127%] None None None

Group 2

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 56dab85 1784024118 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 14.955µs 15.422µs ± 0.148µs 15.403µs ± 0.087µs 15.493µs 15.673µs 15.929µs 15.971µs 3.69% 0.775 1.751 0.96% 0.010µ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.402µs; 15.443µs] or [-0.133%; +0.133%] None None None

Group 3

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 56dab85 1784024118 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
receiver_entry_point/report/2644 execution_time 3.776ms 3.803ms ± 0.016ms 3.800ms ± 0.008ms 3.809ms 3.832ms 3.862ms 3.869ms 1.82% 1.430 2.733 0.43% 0.001ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
receiver_entry_point/report/2644 execution_time [3.801ms; 3.805ms] or [-0.059%; +0.059%] None None None

@dd-octo-sts

dd-octo-sts Bot commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Artifact Size Benchmark Report

aarch64-alpine-linux-musl
Artifact Baseline Commit Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 7.88 MB 7.88 MB 0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 85.89 MB 86.17 MB +.32% (+289.37 KB) 🔍
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 97.11 MB 97.41 MB +.30% (+298.70 KB) 🔍
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 10.61 MB 10.62 MB +.07% (+7.78 KB) 🔍
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 25.45 MB 25.52 MB +.27% (+71.00 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.54 MB 185.01 MB +.25% (+488.00 KB) 🔍
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 946.77 MB 950.44 MB +.38% (+3.67 MB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 8.32 MB 8.34 MB +.27% (+23.50 KB) 🔍
/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.69 MB +.31% (+80.00 KB) 🔍
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 49.03 MB 49.17 MB +.28% (+143.22 KB) 🔍
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 22.05 MB 22.12 MB +.27% (+63.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 189.09 MB +.17% (+344.00 KB) 🔍
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 935.45 MB 938.96 MB +.37% (+3.51 MB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 6.43 MB 6.45 MB +.32% (+21.50 KB) 🔍
/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.52 MB +.35% (+96.00 KB) 🔍
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 46.66 MB 46.80 MB +.29% (+142.74 KB) 🔍
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 76.59 MB 76.84 MB +.32% (+253.64 KB) 🔍
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 8.78 MB 8.80 MB +.22% (+20.00 KB) 🔍
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 92.11 MB 92.37 MB +.27% (+261.31 KB) 🔍
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 10.70 MB 10.72 MB +.23% (+25.39 KB) 🔍

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.

1 participant