chore(deps): bump zrip to 0.8.7 by BridgeAR · Pull Request #2483 · DataDog/libdatadog

BridgeAR · 2026-09-08T14:47:49Z

zrip 0.8.7 requires Rust 1.89, so this moves the dependency and workspace MSRV together. It lets downstream WASM consumers use one zrip version instead of retaining the 0.6.0 stack.

Refs: DataDog/libdatadog-nodejs#270

zrip 0.8.7 requires Rust 1.89, so the dependency and workspace MSRV must move together. Refs: DataDog/libdatadog-nodejs#270

github-actions · 2026-09-08T14:50:30Z

📚 Documentation Check Results

⚠️ 2708 documentation warning(s) found

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

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

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

📦 `libdd-wasm-tests` - ✅ No warnings

Updated: 2026-09-08 14:50:29 UTC | Commit: b6f7e41 | missing-docs job results

github-actions · 2026-09-08T14:51:53Z

🔒 Cargo Deny Results

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

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

Show output

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

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:48:1
   │
48 │ 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-profiling v1.0.0
     │                   └── (dev) libdd-profiling v1.0.0 (*)
     └── moka v0.12.13
         └── hickory-resolver v0.25.2
             └── reqwest v0.13.2
                 ├── libdd-common v5.2.0
                 │   └── libdd-profiling v1.0.0 (*)
                 └── libdd-profiling v1.0.0 (*)

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

📦 `libdd-wasm-tests` - ✅ No issues

Updated: 2026-09-08 14:51:51 UTC | Commit: b6f7e41 | dependency-check job results

datadog-datadog-prod-us1-2 · 2026-09-08T14:59:35Z

✅ All CI checks and tests passed.

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 77.44% (-0.00%)

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

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

pr-commenter · 2026-09-08T15:36:04Z

Benchmarks

Comparison

Benchmark execution time: 2026-09-08 15:28:17

Comparing candidate commit bc290a8 in PR branch BridgeAR/2026-09-08-zrip-0-8-7 with baseline commit bdbad40 in branch main.

📊 Benchmarking dashboard

Found 6 performance improvements and 16 performance regressions! Performance is the same for 131 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:normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて

🟩 execution_time [-28.160µs; -27.988µs] or [-7.499%; -7.453%]
🟩 throughput [+214501.341op/s; +215843.522op/s] or [+8.055%; +8.105%]

scenario:otlp/e2e_json/1x1000

🟥 execution_time [+295.810µs; +297.425µs] or [+7.125%; +7.164%]

scenario:otlp/encode_json/1x1000

🟥 execution_time [+300.683µs; +301.211µs] or [+16.608%; +16.637%]

scenario:profile_serialize_compressed_pprof_timestamped_x1000

🟥 execution_time [+41.116µs; +42.209µs] or [+4.284%; +4.398%]

scenario:vec_map/as_deduped_map/already_deduped/8

🟩 execution_time [-0.815ns; -0.798ns] or [-5.195%; -5.087%]

scenario:vec_map/contains_key/8

🟩 execution_time [-5.296ns; -5.065ns] or [-6.344%; -6.068%]
🟩 throughput [+6199651.557op/s; +6481919.806op/s] or [+6.469%; +6.764%]

scenario:vec_map/get_hit/128

🟥 execution_time [+2.934µs; +2.941µs] or [+21.585%; +21.637%]
🟥 throughput [-1675550.159op/s; -1671521.678op/s] or [-17.792%; -17.749%]

scenario:vec_map/get_hit/16

🟥 execution_time [+49.746ns; +49.945ns] or [+24.843%; +24.942%]
🟥 throughput [-15957079.222op/s; -15894749.008op/s] or [-19.970%; -19.892%]

scenario:vec_map/get_hit/64

🟥 execution_time [+650.398ns; +653.949ns] or [+17.643%; +17.740%]
🟥 throughput [-2617182.035op/s; -2602497.372op/s] or [-15.075%; -14.990%]

scenario:vec_map/get_hit/8

🟥 execution_time [+12.470ns; +12.506ns] or [+23.113%; +23.179%]
🟥 throughput [-27907460.211op/s; -27832009.960op/s] or [-18.821%; -18.770%]

scenario:vec_map/get_miss/128

🟩 execution_time [-4.136ns; -3.919ns] or [-5.117%; -4.848%]

scenario:vec_map/get_miss/16

🟥 execution_time [+17.878ns; +18.093ns] or [+191.054%; +193.361%]

scenario:vec_map/get_miss/64

🟥 execution_time [+22.187ns; +22.267ns] or [+77.308%; +77.588%]

scenario:vec_map/get_miss/8

🟥 execution_time [+10.523ns; +10.686ns] or [+140.200%; +142.364%]

scenario:vec_map/get_mut/128

🟥 execution_time [+681.985ns; +772.261ns] or [+4.963%; +5.620%]
🟥 throughput [-499453.019op/s; -440200.943op/s] or [-5.360%; -4.724%]

Benchmark execution time: 2026-09-08 15:30:03

Comparing candidate commit bc290a8 in PR branch BridgeAR/2026-09-08-zrip-0-8-7 with baseline commit bdbad40 in branch main.

📊 Benchmarking dashboard

Found 12 performance improvements and 14 performance regressions! Performance is the same for 143 metrics, 10 unstable metrics.

Explanation

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

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

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

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

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

More details about the CI and significant changes

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

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

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

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

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

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

scenario:credit_card/is_card_number/x371413321323331

🟩 execution_time [-740.123ns; -737.685ns] or [-11.484%; -11.446%]
🟩 throughput [+20060509.143op/s; +20127095.375op/s] or [+12.928%; +12.971%]

scenario:credit_card/is_card_number_no_luhn/ 3782-8224-6310-005

🟩 execution_time [-3.280µs; -3.141µs] or [-5.069%; -4.855%]
🟩 throughput [+789543.016op/s; +824921.822op/s] or [+5.108%; +5.337%]

scenario:credit_card/is_card_number_no_luhn/x371413321323331

🟩 execution_time [-738.661ns; -736.351ns] or [-11.464%; -11.428%]
🟩 throughput [+20029212.257op/s; +20092547.598op/s] or [+12.905%; +12.946%]

scenario:datadog_sample_span/tag_rule_matching/wall_time

🟩 execution_time [-16.292ns; -16.107ns] or [-4.747%; -4.693%]

scenario:ddsketch_encode/into_pb/clustered_near_zero

🟥 execution_time [+7.410ns; +7.981ns] or [+21.534%; +23.191%]

scenario:ddsketch_encode/into_pb/collapsing

🟥 execution_time [+6.356ns; +8.033ns] or [+16.660%; +21.056%]

scenario:ddsketch_encode/into_pb/large_values

🟥 execution_time [+7.280ns; +7.974ns] or [+20.844%; +22.830%]

scenario:ddsketch_encode/into_pb/mixed

🟥 execution_time [+7.152ns; +8.186ns] or [+19.982%; +22.870%]

scenario:glob_matcher/ascii_case_insensitive_match/wall_time

🟥 execution_time [+2.718ns; +2.742ns] or [+10.202%; +10.291%]

scenario:glob_matcher/ascii_exact_match/wall_time

🟥 execution_time [+2.749ns; +2.769ns] or [+10.319%; +10.396%]

scenario:glob_matcher/ascii_exact_miss/wall_time

🟥 execution_time [+2.701ns; +2.758ns] or [+23.502%; +24.001%]

scenario:glob_matcher/ascii_wildcard_question_match/wall_time

🟩 execution_time [-23.327ns; -23.300ns] or [-38.747%; -38.701%]

scenario:glob_matcher/ascii_wildcard_star_match/wall_time

🟩 execution_time [-22.512ns; -22.484ns] or [-37.905%; -37.860%]

scenario:glob_matcher/unicode_exact_match/wall_time

🟩 execution_time [-3.554ns; -3.493ns] or [-4.822%; -4.739%]

scenario:no_profiler/short_circuit/16

🟥 execution_time [+1.353ns; +1.462ns] or [+5.218%; +5.639%]

scenario:no_profiler/short_circuit/256

🟥 execution_time [+1.371ns; +1.464ns] or [+5.298%; +5.655%]

scenario:no_profiler/short_circuit/64

🟥 execution_time [+1.398ns; +1.513ns] or [+5.393%; +5.835%]

scenario:profiler_attached/fast_path_system/16

🟥 execution_time [+2.112ns; +2.214ns] or [+7.833%; +8.212%]

scenario:profiler_attached/fast_path_system/256

🟥 execution_time [+2.210ns; +2.305ns] or [+8.229%; +8.584%]

scenario:profiler_attached/fast_path_system/4096

🟩 execution_time [-10.683ns; -10.537ns] or [-10.069%; -9.932%]

scenario:profiler_attached/fast_path_system/64

🟥 execution_time [+2.224ns; +2.312ns] or [+8.274%; +8.601%]

scenario:sql/obfuscate_sql_string

🟩 execution_time [-18.887µs; -18.670µs] or [-6.730%; -6.653%]

scenario:tags/replace_trace_tags

🟥 execution_time [+107.650ns; +114.693ns] or [+4.201%; +4.476%]

Unstable benchmarks

These benchmarks have a confidence interval too wide to call a change; treat them as noise rather than signal.

scenario:datadog_sample_span/parent_not_sampled_short_circuit/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+514.755%; -514.814%]

scenario:datadog_sample_span/parent_sampled_short_circuit/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+514.821%; -514.844%]

scenario:glob_matcher/ascii_case_insensitive_match/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+551.117%; -531.171%]

scenario:glob_matcher/ascii_exact_match/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+551.247%; -531.231%]

scenario:glob_matcher/ascii_exact_miss/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+592.082%; -550.293%]

scenario:glob_matcher/ascii_wildcard_backtrack_match/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+518.506%; -516.470%]

scenario:glob_matcher/ascii_wildcard_heavy_backtrack/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+516.397%; -515.538%]

scenario:glob_matcher/ascii_wildcard_question_match/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+515.709%; -515.235%]

scenario:glob_matcher/ascii_wildcard_star_match/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+515.656%; -515.212%]

scenario:glob_matcher/star_short_circuit/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+514.713%; -514.796%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

ekump · 2026-09-09T20:59:26Z

You can't just arbitrarily bump libdatadog's MSRV. We currently have customers using dd-trace-rs with an MSRV below 1.89.

BridgeAR · 2026-09-09T21:09:29Z

@ekump that makes sense. Do we have a documentation for what is considered internal and what must stay as is and what support guarantees we have?

paullegranddc · 2026-09-10T12:10:16Z

Do we have a documentation for what is considered internal and what must stay as is and what support guarantees we have?

We have a policy of being at least 1 year behind the latest rust version. So 1.89 would be fine, except for the fact that we already bumped the MSRV 3 months ago.
Bumping the MSRV would require a new major version of dd-trace-rs and we're not ready to do it that often

ekump · 2026-09-10T12:44:57Z

Do we have a documentation for what is considered internal and what must stay as is and what support guarantees we have?

@BridgeAR - The documentation is a bit disjointed at the moment. I'll fix that so we have something clear. We also need to officially publish the dd-trace-rs support policy. As @paullegranddc said, when we bump the MSRV of dd-trace-rs we bump to at most one year behind latest. I'll discuss with the libdatadog guild, and our team and figure out how soon we can update the MSRV again, hopefully in Q4.

chore(deps): bump zrip to 0.8.7

bc290a8

zrip 0.8.7 requires Rust 1.89, so the dependency and workspace MSRV must move together. Refs: DataDog/libdatadog-nodejs#270

github-actions Bot added mini-agent data-pipeline labels Sep 8, 2026

BridgeAR marked this pull request as ready for review September 8, 2026 14:55

BridgeAR requested review from a team as code owners September 8, 2026 14:55

BridgeAR marked this pull request as draft September 11, 2026 10:31

Uh oh!

Conversation

BridgeAR commented Sep 8, 2026

Uh oh!

github-actions Bot commented Sep 8, 2026

📚 Documentation Check Results

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

📦 libdd-profiling - 649 warning(s)

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

📦 libdd-wasm-tests - ✅ No warnings

Uh oh!

github-actions Bot commented Sep 8, 2026

🔒 Cargo Deny Results

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

📦 libdd-profiling - 6 error(s)

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

📦 libdd-wasm-tests - ✅ No issues

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

Benchmarks

Comparison

Explanation

More details about the CI and significant changes

scenario:normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて

scenario:otlp/e2e_json/1x1000

scenario:otlp/encode_json/1x1000

scenario:profile_serialize_compressed_pprof_timestamped_x1000

scenario:vec_map/as_deduped_map/already_deduped/8

scenario:vec_map/contains_key/8

scenario:vec_map/get_hit/128

scenario:vec_map/get_hit/16

scenario:vec_map/get_hit/64

scenario:vec_map/get_hit/8

scenario:vec_map/get_miss/128

scenario:vec_map/get_miss/16

scenario:vec_map/get_miss/64

scenario:vec_map/get_miss/8

scenario:vec_map/get_mut/128

Explanation

More details about the CI and significant changes

scenario:credit_card/is_card_number/x371413321323331

scenario:credit_card/is_card_number_no_luhn/ 3782-8224-6310-005

scenario:credit_card/is_card_number_no_luhn/x371413321323331

scenario:datadog_sample_span/tag_rule_matching/wall_time

scenario:ddsketch_encode/into_pb/clustered_near_zero

scenario:ddsketch_encode/into_pb/collapsing

scenario:ddsketch_encode/into_pb/large_values

scenario:ddsketch_encode/into_pb/mixed

scenario:glob_matcher/ascii_case_insensitive_match/wall_time

scenario:glob_matcher/ascii_exact_match/wall_time

scenario:glob_matcher/ascii_exact_miss/wall_time

scenario:glob_matcher/ascii_wildcard_question_match/wall_time

scenario:glob_matcher/ascii_wildcard_star_match/wall_time

scenario:glob_matcher/unicode_exact_match/wall_time

scenario:no_profiler/short_circuit/16

scenario:no_profiler/short_circuit/256

scenario:no_profiler/short_circuit/64

scenario:profiler_attached/fast_path_system/16

scenario:profiler_attached/fast_path_system/256

scenario:profiler_attached/fast_path_system/4096

scenario:profiler_attached/fast_path_system/64

scenario:sql/obfuscate_sql_string

scenario:tags/replace_trace_tags

Unstable benchmarks

scenario:datadog_sample_span/parent_not_sampled_short_circuit/allocated_bytes

scenario:datadog_sample_span/parent_sampled_short_circuit/allocated_bytes

scenario:glob_matcher/ascii_case_insensitive_match/allocated_bytes

scenario:glob_matcher/ascii_exact_match/allocated_bytes

scenario:glob_matcher/ascii_exact_miss/allocated_bytes

scenario:glob_matcher/ascii_wildcard_backtrack_match/allocated_bytes

scenario:glob_matcher/ascii_wildcard_heavy_backtrack/allocated_bytes

scenario:glob_matcher/ascii_wildcard_question_match/allocated_bytes

scenario:glob_matcher/ascii_wildcard_star_match/allocated_bytes

scenario:glob_matcher/star_short_circuit/allocated_bytes

Candidate

Baseline

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

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

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

📦 `libdd-wasm-tests` - ✅ No warnings

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

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

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

📦 `libdd-wasm-tests` - ✅ No issues

datadog-datadog-prod-us1-2 Bot commented Sep 8, 2026 •

edited by datadog-prod-us1-3 Bot

Loading

pr-commenter Bot commented Sep 8, 2026 •

edited

Loading