feat(wasm): make trivial changes for wasm compatibility

[Aaalibaba42]

What does this PR do?

Make getRandom use the "js" feature if we are targetting wasm32. Don't depend on sys-info crate if we compile to wasm. Use web_time instead of time (zero overhead on native, and works ootb with wasm32-unknown-unknown

Motivation

Part of the effort to make libdatadog wasm-compatible (at least relevant parts of it).

Additional Notes

/

How to test the change?

It's hard to know exactly, for nothing compiles on wasm just yet. You can compare the kind of error before and after for each crate and see they are not the same, you can cargo tree or cargo metadata and see if the crates we eliminated/consolidated on features flags indeed are etc.

[github-actions]

📚 Documentation Check Results

⚠️ 1847 documentation warning(s) found

📦 libdd-common - 155 warning(s)

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

📦 libdd-telemetry - 464 warning(s)

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

---

Updated: 2026-02-10 13:12:59 UTC | Commit: a01696d | missing-docs job results

[github-actions]

Clippy Allow Annotation Report

Comparing clippy allow annotations between branches:

• Base Branch: origin/main
• PR Branch: origin/jwiriath/get-random-js-feature-for-wasm

Summary by Rule

Rule	Base Branch	PR Branch	Change
unwrap_used	13	13	No change (0%)
Total	13	13	No change (0%)

Annotation Counts by File

File	Base Branch	PR Branch	Change
libdd-telemetry/src/worker/mod.rs	13	13	No change (0%)

Annotation Stats by Crate

Crate	Base Branch	PR Branch	Change
clippy-annotation-reporter	5	0	✅ -5 (-100.0%)
datadog-ffe-ffi	1	1	No change (0%)
datadog-ipc	27	27	No change (0%)
datadog-live-debugger	6	6	No change (0%)
datadog-live-debugger-ffi	10	10	No change (0%)
datadog-profiling-replayer	4	4	No change (0%)
datadog-remote-config	3	3	No change (0%)
datadog-sidecar	59	59	No change (0%)
libdd-common	10	10	No change (0%)
libdd-common-ffi	12	12	No change (0%)
libdd-crashtracker	12	12	No change (0%)
libdd-data-pipeline	6	6	No change (0%)
libdd-ddsketch	2	2	No change (0%)
libdd-dogstatsd-client	1	1	No change (0%)
libdd-profiling	13	13	No change (0%)
libdd-telemetry	19	19	No change (0%)
libdd-tinybytes	4	4	No change (0%)
libdd-trace-normalization	2	2	No change (0%)
libdd-trace-obfuscation	9	9	No change (0%)
libdd-trace-utils	15	15	No change (0%)
Total	220	215	✅ -5 (-2.3%)

About This Report

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

[github-actions]

🔒 Cargo Deny Results

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

📦 libdd-common - 6 error(s)

Show output

error[vulnerability]: Integer overflow in `BytesMut::reserve`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:18:1
   │
18 │ bytes 1.8.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0007
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0007
   ├ In the unique reclaim path of `BytesMut::reserve`, the condition
     ```rs
     if v_capacity >= new_cap + offset
     ```
     uses an unchecked addition. When `new_cap + offset` overflows `usize` in release builds, this condition may incorrectly pass, causing `self.cap` to be set to a value that exceeds the actual allocated capacity. Subsequent APIs such as `spare_capacity_mut()` then trust this corrupted `cap` value and may create out-of-bounds slices, leading to UB.
     
     This behavior is observable in release builds (integer overflow wraps), whereas debug builds panic due to overflow checks.
     
     ## PoC
     
     ```rs
     use bytes::*;
     
     fn main() {
         let mut a = BytesMut::from(&b"hello world"[..]);
         let mut b = a.split_off(5);
     
         // Ensure b becomes the unique owner of the backing storage
         drop(a);
     
         // Trigger overflow in new_cap + offset inside reserve
         b.reserve(usize::MAX - 6);
     
         // This call relies on the corrupted cap and may cause UB & HBO
         b.put_u8(b'h');
     }
     ```
     
     # Workarounds
     
     Users of `BytesMut::reserve` are only affected if integer overflow checks are configured to wrap. When integer overflow is configured to panic, this issue does not apply.
   ├ Announcement: https://github.com/advisories/GHSA-434x-w66g-qw3r
   ├ Solution: Upgrade to >=1.11.1 (try `cargo update -p bytes`)
   ├ bytes v1.8.0
     ├── combine v4.6.7
     │   └── jni v0.21.1
     │       └── rustls-platform-verifier v0.6.2
     │           └── reqwest v0.13.1
     │               └── libdd-common v1.1.0
     ├── http v1.1.0
     │   ├── http-body v1.0.1
     │   │   ├── http-body-util v0.1.2
     │   │   │   ├── libdd-common v1.1.0 (*)
     │   │   │   └── reqwest v0.13.1 (*)
     │   │   ├── hyper v1.6.0
     │   │   │   ├── hyper-rustls v0.27.3
     │   │   │   │   ├── libdd-common v1.1.0 (*)
     │   │   │   │   └── reqwest v0.13.1 (*)
     │   │   │   ├── hyper-util v0.1.17
     │   │   │   │   ├── hyper-rustls v0.27.3 (*)
     │   │   │   │   ├── libdd-common v1.1.0 (*)
     │   │   │   │   └── reqwest v0.13.1 (*)
     │   │   │   ├── libdd-common v1.1.0 (*)
     │   │   │   └── reqwest v0.13.1 (*)
     │   │   ├── hyper-util v0.1.17 (*)
     │   │   ├── libdd-common v1.1.0 (*)
     │   │   ├── reqwest v0.13.1 (*)
     │   │   └── tower-http v0.6.8
     │   │       └── reqwest v0.13.1 (*)
     │   ├── http-body-util v0.1.2 (*)
     │   ├── hyper v1.6.0 (*)
     │   ├── hyper-rustls v0.27.3 (*)
     │   ├── hyper-util v0.1.17 (*)
     │   ├── libdd-common v1.1.0 (*)
     │   ├── reqwest v0.13.1 (*)
     │   └── tower-http v0.6.8 (*)
     ├── http-body v1.0.1 (*)
     ├── http-body-util v0.1.2 (*)
     ├── hyper v1.6.0 (*)
     ├── hyper-util v0.1.17 (*)
     ├── reqwest v0.13.1 (*)
     ├── tokio v1.49.0
     │   ├── hyper v1.6.0 (*)
     │   ├── hyper-rustls v0.27.3 (*)
     │   ├── hyper-util v0.1.17 (*)
     │   ├── (dev) libdd-common v1.1.0 (*)
     │   ├── reqwest v0.13.1 (*)
     │   ├── tokio-rustls v0.26.0
     │   │   ├── hyper-rustls v0.27.3 (*)
     │   │   ├── libdd-common v1.1.0 (*)
     │   │   └── reqwest v0.13.1 (*)
     │   └── tower v0.5.2
     │       ├── reqwest v0.13.1 (*)
     │       └── tower-http v0.6.8 (*)
     └── tower-http v0.6.8 (*)

error[vulnerability]: Lenient `hyper` header parsing of `Content-Length` could allow request smuggling
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:65:1
   │
65 │ hyper 0.10.16 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2021-0078
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2021-0078
   ├ `hyper`'s HTTP header parser accepted, according to RFC 7230, illegal contents inside `Content-Length` headers.
     Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error.
     
     To be vulnerable, `hyper` must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents
     but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.
   ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-f3pg-qwvg-p99c
   ├ Solution: Upgrade to >=0.14.10 (try `cargo update -p hyper`)
   ├ hyper v0.10.16
     ├── iron v0.6.1
     │   └── multipart v0.18.0
     │       └── libdd-common v1.1.0
     ├── multipart v0.18.0 (*)
     └── nickel v0.11.0
         └── multipart v0.18.0 (*)

error[vulnerability]: Integer overflow in `hyper`'s parsing of the `Transfer-Encoding` header leads to data loss
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:65:1
   │
65 │ hyper 0.10.16 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2021-0079
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2021-0079
   ├ When decoding chunk sizes that are too large, `hyper`'s code would encounter an integer overflow. Depending on the situation,
     this could lead to data loss from an incorrect total size, or in rarer cases, a request smuggling attack.
     
     To be vulnerable, you must be using `hyper` for any HTTP/1 purpose, including as a client or server, and consumers must send
     requests or responses that specify a chunk size greater than 18 exabytes. For a possible request smuggling attack to be possible,
     any upstream proxies must accept a chunk size greater than 64 bits.
   ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-5h46-h7hh-c6x9
   ├ Solution: Upgrade to >=0.14.10 (try `cargo update -p hyper`)
   ├ hyper v0.10.16
     ├── iron v0.6.1
     │   └── multipart v0.18.0
     │       └── libdd-common v1.1.0
     ├── multipart v0.18.0 (*)
     └── nickel v0.11.0
         └── multipart v0.18.0 (*)

error[vulnerability]: `idna` accepts Punycode labels that do not produce any non-ASCII when decoded
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:81:1
   │
81 │ idna 0.1.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2024-0421
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0421
   ├ `idna` 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with `idna` 0.5.0 or earlier.
     
     Concretely, `example.org` and `xn--example-.org` become equal after processing by `idna` 0.5.0 or earlier. Also, `example.org.xn--` and `example.org.` become equal after processing by `idna` 0.5.0 or earlier.
     
     In applications using `idna` (but not in `idna` itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an `xn--`-masked name that turns into the name of the target when processed by `idna` 0.5.0 or earlier.
     
     ## Remedy
     
     Upgrade to `idna` 1.0.3 or later, if depending on `idna` directly, or to `url` 2.5.4 or later, if depending on `idna` via `url`. (This issue was fixed in `idna` 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)
     
     When upgrading, please take a moment to read about [alternative Unicode back ends for `idna`](https://docs.rs/crate/idna_adapter/latest).
     
     If you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an [issue](https://github.com/servo/rust-url/issues/992) about combining them with `url` 2.5.4 and `idna` 1.0.3.
     
     ## Additional information
     
     This issue resulted from `idna` 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in [revision 33 of UTS 46](https://www.unicode.org/reports/tr46/tr46-33.html#Modifications).
     
     ## Acknowledgements
     
     Thanks to kageshiron for recognizing the security implications of this behavior.
   ├ Announcement: https://bugzilla.mozilla.org/show_bug.cgi?id=1887898
   ├ Solution: Upgrade to >=1.0.0 (try `cargo update -p idna`)
   ├ idna v0.1.5
     └── url v1.7.2
         ├── hyper v0.10.16
         │   ├── iron v0.6.1
         │   │   └── multipart v0.18.0
         │   │       └── libdd-common v1.1.0
         │   ├── multipart v0.18.0 (*)
         │   └── nickel v0.11.0
         │       └── multipart v0.18.0 (*)
         ├── iron v0.6.1 (*)
         ├── nickel v0.11.0 (*)
         └── tiny_http v0.6.4
             └── multipart v0.18.0 (*)

error[unmaintained]: multipart is Unmaintained
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:115:1
    │
115 │ multipart 0.18.0 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
    │
    ├ ID: RUSTSEC-2023-0050
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2023-0050
    ├ The `multipart` crate is unmaintained. The author has archived the github
      repository.
      
      Alternatives:
      
      - [multer](https://crates.io/crates/multer)
      - [multiparty](https://crates.io/crates/multiparty)
    ├ Solution: No safe upgrade is available!
    ├ multipart v0.18.0
      └── libdd-common v1.1.0

error[vulnerability]: Potential segfault in the time crate
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:194:1
    │
194 │ time 0.1.45 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2020-0071
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2020-0071
    ├ ### Impact
      
      The affected functions set environment variables without synchronization. On Unix-like operating systems, this can crash in multithreaded programs. Programs may segfault due to dereferencing a dangling pointer if an environment variable is read in a different thread than the affected functions. This may occur without the user's knowledge, notably in the Rust standard library or third-party libraries.
      
      The affected functions from time 0.2.7 through 0.2.22 are:
      
      - `time::UtcOffset::local_offset_at`
      - `time::UtcOffset::try_local_offset_at`
      - `time::UtcOffset::current_local_offset`
      - `time::UtcOffset::try_current_local_offset`
      - `time::OffsetDateTime::now_local`
      - `time::OffsetDateTime::try_now_local`
      
      The affected functions in time 0.1 (all versions) are:
      
      - `time::at_utc`
      - `time::at`
      - `time::now`
      - `time::tzset`
      
      Non-Unix targets (including Windows and wasm) are unaffected.
      
      ### Patches
      
      Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods.
      
      Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code.
      
      Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.
      
      ### Workarounds
      
      A possible workaround for crates affected through the transitive dependency in `chrono`, is to avoid using the default `oldtime` feature dependency of the `chrono` crate by disabling its `default-features` and manually specifying the required features instead.
      
      #### Examples:
      
      `Cargo.toml`:  
      
      ```toml
      chrono = { version = "0.4", default-features = false, features = ["serde"] }
      ```
      
      ```toml
      chrono = { version = "0.4.22", default-features = false, features = ["clock"] }
      ```
      
      Commandline:  
      
      ```bash
      cargo add chrono --no-default-features -F clock
      ```
      
      Sources:  
       - [chronotope/chrono#602 (comment)](https://github.com/chronotope/chrono/issues/602#issuecomment-1242149249)  
       - [vityafx/serde-aux#21](https://github.com/vityafx/serde-aux/issues/21)
    ├ Announcement: https://github.com/time-rs/time/issues/293
    ├ Solution: Upgrade to >=0.2.23 (try `cargo update -p time`)
    ├ time v0.1.45
      ├── hyper v0.10.16
      │   ├── iron v0.6.1
      │   │   └── multipart v0.18.0
      │   │       └── libdd-common v1.1.0
      │   ├── multipart v0.18.0 (*)
      │   └── nickel v0.11.0
      │       └── multipart v0.18.0 (*)
      └── nickel v0.11.0 (*)

advisories FAILED, bans ok, sources ok

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

Show output

error[vulnerability]: Integer overflow in `BytesMut::reserve`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:55:1
   │
55 │ bytes 1.8.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0007
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0007
   ├ In the unique reclaim path of `BytesMut::reserve`, the condition
     ```rs
     if v_capacity >= new_cap + offset
     ```
     uses an unchecked addition. When `new_cap + offset` overflows `usize` in release builds, this condition may incorrectly pass, causing `self.cap` to be set to a value that exceeds the actual allocated capacity. Subsequent APIs such as `spare_capacity_mut()` then trust this corrupted `cap` value and may create out-of-bounds slices, leading to UB.
     
     This behavior is observable in release builds (integer overflow wraps), whereas debug builds panic due to overflow checks.
     
     ## PoC
     
     ```rs
     use bytes::*;
     
     fn main() {
         let mut a = BytesMut::from(&b"hello world"[..]);
         let mut b = a.split_off(5);
     
         // Ensure b becomes the unique owner of the backing storage
         drop(a);
     
         // Trigger overflow in new_cap + offset inside reserve
         b.reserve(usize::MAX - 6);
     
         // This call relies on the corrupted cap and may cause UB & HBO
         b.put_u8(b'h');
     }
     ```
     
     # Workarounds
     
     Users of `BytesMut::reserve` are only affected if integer overflow checks are configured to wrap. When integer overflow is configured to panic, this issue does not apply.
   ├ Announcement: https://github.com/advisories/GHSA-434x-w66g-qw3r
   ├ Solution: Upgrade to >=1.11.1 (try `cargo update -p bytes`)
   ├ bytes v1.8.0
     ├── h2 v0.4.6
     │   └── hyper v1.6.0
     │       ├── httpmock v0.8.0-alpha.1
     │       │   ├── (dev) libdd-data-pipeline v1.0.0
     │       │   └── libdd-trace-utils v1.0.0
     │       │       ├── libdd-data-pipeline v1.0.0 (*)
     │       │       ├── libdd-trace-stats v1.0.0
     │       │       │   └── libdd-data-pipeline v1.0.0 (*)
     │       │       └── (dev) libdd-trace-utils v1.0.0 (*)
     │       ├── hyper-rustls v0.27.3
     │       │   └── libdd-common v1.1.0
     │       │       ├── libdd-data-pipeline v1.0.0 (*)
     │       │       ├── libdd-dogstatsd-client v1.0.0
     │       │       │   └── libdd-data-pipeline v1.0.0 (*)
     │       │       ├── libdd-telemetry v2.0.0
     │       │       │   └── libdd-data-pipeline v1.0.0 (*)
     │       │       └── libdd-trace-utils v1.0.0 (*)
     │       ├── hyper-util v0.1.17
     │       │   ├── httpmock v0.8.0-alpha.1 (*)
     │       │   ├── hyper-rustls v0.27.3 (*)
     │       │   ├── libdd-common v1.1.0 (*)
     │       │   ├── libdd-data-pipeline v1.0.0 (*)
     │       │   └── libdd-telemetry v2.0.0 (*)
     │       ├── libdd-common v1.1.0 (*)
     │       ├── libdd-data-pipeline v1.0.0 (*)
     │       ├── libdd-telemetry v2.0.0 (*)
     │       └── libdd-trace-utils v1.0.0 (*)
     ├── headers v0.4.0
     │   └── httpmock v0.8.0-alpha.1 (*)
     ├── http v1.1.0
     │   ├── h2 v0.4.6 (*)
     │   ├── headers v0.4.0 (*)
     │   ├── headers-core v0.3.0
     │   │   └── headers v0.4.0 (*)
     │   ├── http-body v1.0.1
     │   │   ├── http-body-util v0.1.2
     │   │   │   ├── httpmock v0.8.0-alpha.1 (*)
     │   │   │   ├── libdd-common v1.1.0 (*)
     │   │   │   ├── libdd-data-pipeline v1.0.0 (*)
     │   │   │   ├── libdd-telemetry v2.0.0 (*)
     │   │   │   └── libdd-trace-utils v1.0.0 (*)
     │   │   ├── hyper v1.6.0 (*)
     │   │   ├── hyper-util v0.1.17 (*)
     │   │   └── libdd-common v1.1.0 (*)
     │   ├── http-body-util v0.1.2 (*)
     │   ├── httpmock v0.8.0-alpha.1 (*)
     │   ├── hyper v1.6.0 (*)
     │   ├── hyper-rustls v0.27.3 (*)
     │   ├── hyper-util v0.1.17 (*)
     │   ├── libdd-common v1.1.0 (*)
     │   ├── libdd-data-pipeline v1.0.0 (*)
     │   ├── libdd-dogstatsd-client v1.0.0 (*)
     │   ├── libdd-telemetry v2.0.0 (*)
     │   └── libdd-trace-utils v1.0.0 (*)
     ├── http-body v1.0.1 (*)
     ├── http-body-util v0.1.2 (*)
     ├── httpmock v0.8.0-alpha.1 (*)
     ├── hyper v1.6.0 (*)
     ├── hyper-util v0.1.17 (*)
     ├── libdd-data-pipeline v1.0.0 (*)
     ├── libdd-trace-utils v1.0.0 (*)
     ├── prost v0.14.3
     │   ├── libdd-ddsketch v1.0.0
     │   │   ├── libdd-data-pipeline v1.0.0 (*)
     │   │   ├── libdd-telemetry v2.0.0 (*)
     │   │   └── libdd-trace-stats v1.0.0 (*)
     │   ├── libdd-trace-protobuf v1.0.0
     │   │   ├── libdd-data-pipeline v1.0.0 (*)
     │   │   ├── libdd-trace-normalization v1.0.0
     │   │   │   └── libdd-trace-utils v1.0.0 (*)
     │   │   ├── libdd-trace-stats v1.0.0 (*)
     │   │   └── libdd-trace-utils v1.0.0 (*)
     │   └── libdd-trace-utils v1.0.0 (*)
     ├── tokio v1.49.0
     │   ├── h2 v0.4.6 (*)
     │   ├── httpmock v0.8.0-alpha.1 (*)
     │   ├── hyper v1.6.0 (*)
     │   ├── hyper-rustls v0.27.3 (*)
     │   ├── hyper-util v0.1.17 (*)
     │   ├── (dev) libdd-common v1.1.0 (*)
     │   ├── (dev) libdd-data-pipeline v1.0.0 (*)
     │   ├── (dev) libdd-dogstatsd-client v1.0.0 (*)
     │   ├── (dev) libdd-telemetry v2.0.0 (*)
     │   ├── (dev) libdd-trace-protobuf v1.0.0 (*)
     │   ├── (dev) libdd-trace-utils v1.0.0 (*)
     │   ├── tokio-rustls v0.26.0
     │   │   ├── hyper-rustls v0.27.3 (*)
     │   │   └── libdd-common v1.1.0 (*)
     │   └── tokio-util v0.7.12
     │       ├── h2 v0.4.6 (*)
     │       ├── libdd-data-pipeline v1.0.0 (*)
     │       └── libdd-telemetry v2.0.0 (*)
     └── tokio-util v0.7.12 (*)

error[vulnerability]: Lenient `hyper` header parsing of `Content-Length` could allow request smuggling
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:146:1
    │
146 │ hyper 0.10.16 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2021-0078
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2021-0078
    ├ `hyper`'s HTTP header parser accepted, according to RFC 7230, illegal contents inside `Content-Length` headers.
      Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error.
      
      To be vulnerable, `hyper` must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents
      but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-f3pg-qwvg-p99c
    ├ Solution: Upgrade to >=0.14.10 (try `cargo update -p hyper`)
    ├ hyper v0.10.16
      ├── iron v0.6.1
      │   └── multipart v0.18.0
      │       └── (dev) libdd-common v1.1.0
      │           ├── libdd-data-pipeline v1.0.0
      │           ├── libdd-dogstatsd-client v1.0.0
      │           │   └── libdd-data-pipeline v1.0.0 (*)
      │           ├── libdd-telemetry v2.0.0
      │           │   └── libdd-data-pipeline v1.0.0 (*)
      │           └── libdd-trace-utils v1.0.0
      │               ├── libdd-data-pipeline v1.0.0 (*)
      │               ├── libdd-trace-stats v1.0.0
      │               │   └── libdd-data-pipeline v1.0.0 (*)
      │               └── (dev) libdd-trace-utils v1.0.0 (*)
      ├── multipart v0.18.0 (*)
      └── nickel v0.11.0
          └── multipart v0.18.0 (*)

error[vulnerability]: Integer overflow in `hyper`'s parsing of the `Transfer-Encoding` header leads to data loss
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:146:1
    │
146 │ hyper 0.10.16 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2021-0079
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2021-0079
    ├ When decoding chunk sizes that are too large, `hyper`'s code would encounter an integer overflow. Depending on the situation,
      this could lead to data loss from an incorrect total size, or in rarer cases, a request smuggling attack.
      
      To be vulnerable, you must be using `hyper` for any HTTP/1 purpose, including as a client or server, and consumers must send
      requests or responses that specify a chunk size greater than 18 exabytes. For a possible request smuggling attack to be possible,
      any upstream proxies must accept a chunk size greater than 64 bits.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-5h46-h7hh-c6x9
    ├ Solution: Upgrade to >=0.14.10 (try `cargo update -p hyper`)
    ├ hyper v0.10.16
      ├── iron v0.6.1
      │   └── multipart v0.18.0
      │       └── (dev) libdd-common v1.1.0
      │           ├── libdd-data-pipeline v1.0.0
      │           ├── libdd-dogstatsd-client v1.0.0
      │           │   └── libdd-data-pipeline v1.0.0 (*)
      │           ├── libdd-telemetry v2.0.0
      │           │   └── libdd-data-pipeline v1.0.0 (*)
      │           └── libdd-trace-utils v1.0.0
      │               ├── libdd-data-pipeline v1.0.0 (*)
      │               ├── libdd-trace-stats v1.0.0
      │               │   └── libdd-data-pipeline v1.0.0 (*)
      │               └── (dev) libdd-trace-utils v1.0.0 (*)
      ├── multipart v0.18.0 (*)
      └── nickel v0.11.0
          └── multipart v0.18.0 (*)

error[vulnerability]: `idna` accepts Punycode labels that do not produce any non-ASCII when decoded
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:162:1
    │
162 │ idna 0.1.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2024-0421
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0421
    ├ `idna` 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with `idna` 0.5.0 or earlier.
      
      Concretely, `example.org` and `xn--example-.org` become equal after processing by `idna` 0.5.0 or earlier. Also, `example.org.xn--` and `example.org.` become equal after processing by `idna` 0.5.0 or earlier.
      
      In applications using `idna` (but not in `idna` itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an `xn--`-masked name that turns into the name of the target when processed by `idna` 0.5.0 or earlier.
      
      ## Remedy
      
      Upgrade to `idna` 1.0.3 or later, if depending on `idna` directly, or to `url` 2.5.4 or later, if depending on `idna` via `url`. (This issue was fixed in `idna` 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)
      
      When upgrading, please take a moment to read about [alternative Unicode back ends for `idna`](https://docs.rs/crate/idna_adapter/latest).
      
      If you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an [issue](https://github.com/servo/rust-url/issues/992) about combining them with `url` 2.5.4 and `idna` 1.0.3.
      
      ## Additional information
      
      This issue resulted from `idna` 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in [revision 33 of UTS 46](https://www.unicode.org/reports/tr46/tr46-33.html#Modifications).
      
      ## Acknowledgements
      
      Thanks to kageshiron for recognizing the security implications of this behavior.
    ├ Announcement: https://bugzilla.mozilla.org/show_bug.cgi?id=1887898
    ├ Solution: Upgrade to >=1.0.0 (try `cargo update -p idna`)
    ├ idna v0.1.5
      └── url v1.7.2
          ├── hyper v0.10.16
          │   ├── iron v0.6.1
          │   │   └── multipart v0.18.0
          │   │       └── (dev) libdd-common v1.1.0
          │   │           ├── libdd-data-pipeline v1.0.0
          │   │           ├── libdd-dogstatsd-client v1.0.0
          │   │           │   └── libdd-data-pipeline v1.0.0 (*)
          │   │           ├── libdd-telemetry v2.0.0
          │   │           │   └── libdd-data-pipeline v1.0.0 (*)
          │   │           └── libdd-trace-utils v1.0.0
          │   │               ├── libdd-data-pipeline v1.0.0 (*)
          │   │               ├── libdd-trace-stats v1.0.0
          │   │               │   └── libdd-data-pipeline v1.0.0 (*)
          │   │               └── (dev) libdd-trace-utils v1.0.0 (*)
          │   ├── multipart v0.18.0 (*)
          │   └── nickel v0.11.0
          │       └── multipart v0.18.0 (*)
          ├── iron v0.6.1 (*)
          ├── nickel v0.11.0 (*)
          └── tiny_http v0.6.4
              └── multipart v0.18.0 (*)

error[unmaintained]: multipart is Unmaintained
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:208:1
    │
208 │ multipart 0.18.0 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
    │
    ├ ID: RUSTSEC-2023-0050
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2023-0050
    ├ The `multipart` crate is unmaintained. The author has archived the github
      repository.
      
      Alternatives:
      
      - [multer](https://crates.io/crates/multer)
      - [multiparty](https://crates.io/crates/multiparty)
    ├ Solution: No safe upgrade is available!
    ├ multipart v0.18.0
      └── (dev) libdd-common v1.1.0
          ├── libdd-data-pipeline v1.0.0
          ├── libdd-dogstatsd-client v1.0.0
          │   └── libdd-data-pipeline v1.0.0 (*)
          ├── libdd-telemetry v2.0.0
          │   └── libdd-data-pipeline v1.0.0 (*)
          └── libdd-trace-utils v1.0.0
              ├── libdd-data-pipeline v1.0.0 (*)
              ├── libdd-trace-stats v1.0.0
              │   └── libdd-data-pipeline v1.0.0 (*)
              └── (dev) libdd-trace-utils v1.0.0 (*)

error[vulnerability]: Potential segfault in the time crate
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:334:1
    │
334 │ time 0.1.45 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2020-0071
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2020-0071
    ├ ### Impact
      
      The affected functions set environment variables without synchronization. On Unix-like operating systems, this can crash in multithreaded programs. Programs may segfault due to dereferencing a dangling pointer if an environment variable is read in a different thread than the affected functions. This may occur without the user's knowledge, notably in the Rust standard library or third-party libraries.
      
      The affected functions from time 0.2.7 through 0.2.22 are:
      
      - `time::UtcOffset::local_offset_at`
      - `time::UtcOffset::try_local_offset_at`
      - `time::UtcOffset::current_local_offset`
      - `time::UtcOffset::try_current_local_offset`
      - `time::OffsetDateTime::now_local`
      - `time::OffsetDateTime::try_now_local`
      
      The affected functions in time 0.1 (all versions) are:
      
      - `time::at_utc`
      - `time::at`
      - `time::now`
      - `time::tzset`
      
      Non-Unix targets (including Windows and wasm) are unaffected.
      
      ### Patches
      
      Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods.
      
      Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code.
      
      Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.
      
      ### Workarounds
      
      A possible workaround for crates affected through the transitive dependency in `chrono`, is to avoid using the default `oldtime` feature dependency of the `chrono` crate by disabling its `default-features` and manually specifying the required features instead.
      
      #### Examples:
      
      `Cargo.toml`:  
      
      ```toml
      chrono = { version = "0.4", default-features = false, features = ["serde"] }
      ```
      
      ```toml
      chrono = { version = "0.4.22", default-features = false, features = ["clock"] }
      ```
      
      Commandline:  
      
      ```bash
      cargo add chrono --no-default-features -F clock
      ```
      
      Sources:  
       - [chronotope/chrono#602 (comment)](https://github.com/chronotope/chrono/issues/602#issuecomment-1242149249)  
       - [vityafx/serde-aux#21](https://github.com/vityafx/serde-aux/issues/21)
    ├ Announcement: https://github.com/time-rs/time/issues/293
    ├ Solution: Upgrade to >=0.2.23 (try `cargo update -p time`)
    ├ time v0.1.45
      ├── hyper v0.10.16
      │   ├── iron v0.6.1
      │   │   └── multipart v0.18.0
      │   │       └── (dev) libdd-common v1.1.0
      │   │           ├── libdd-data-pipeline v1.0.0
      │   │           ├── libdd-dogstatsd-client v1.0.0
      │   │           │   └── libdd-data-pipeline v1.0.0 (*)
      │   │           ├── libdd-telemetry v2.0.0
      │   │           │   └── libdd-data-pipeline v1.0.0 (*)
      │   │           └── libdd-trace-utils v1.0.0
      │   │               ├── libdd-data-pipeline v1.0.0 (*)
      │   │               ├── libdd-trace-stats v1.0.0
      │   │               │   └── libdd-data-pipeline v1.0.0 (*)
      │   │               └── (dev) libdd-trace-utils v1.0.0 (*)
      │   ├── multipart v0.18.0 (*)
      │   └── nickel v0.11.0
      │       └── multipart v0.18.0 (*)
      └── nickel v0.11.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:335:1
    │
335 │ 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 v1.0.0

error[vulnerability]: Logging user input may result in poisoning logs with ANSI escape sequences
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:354:1
    │
354 │ tracing-subscriber 0.3.19 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2025-0055
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0055
    ├ Previous versions of tracing-subscriber were vulnerable to ANSI escape sequence injection attacks. Untrusted user input containing ANSI escape sequences could be injected into terminal output when logged, potentially allowing attackers to:
      
      - Manipulate terminal title bars
      - Clear screens or modify terminal display
      - Potentially mislead users through terminal manipulation
      
      In isolation, impact is minimal, however security issues have been found in terminal emulators that enabled an attacker to use ANSI escape sequences via logs to exploit vulnerabilities in the terminal emulator.
      
      This was patched in [PR #3368](https://github.com/tokio-rs/tracing/pull/3368) to escape ANSI control characters from user input.
    ├ Announcement: https://github.com/advisories/GHSA-xwfj-jgwm-7wp5
    ├ Solution: Upgrade to >=0.3.20 (try `cargo update -p tracing-subscriber`)
    ├ tracing-subscriber v0.3.19
      ├── libdd-log v1.0.0
      │   └── (dev) libdd-data-pipeline v1.0.0
      ├── (dev) libdd-telemetry v2.0.0
      │   └── libdd-data-pipeline v1.0.0 (*)
      └── tracing-appender v0.2.3
          └── libdd-log v1.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-telemetry - 7 error(s)

Show output

error[vulnerability]: Integer overflow in `BytesMut::reserve`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:19:1
   │
19 │ bytes 1.8.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0007
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0007
   ├ In the unique reclaim path of `BytesMut::reserve`, the condition
     ```rs
     if v_capacity >= new_cap + offset
     ```
     uses an unchecked addition. When `new_cap + offset` overflows `usize` in release builds, this condition may incorrectly pass, causing `self.cap` to be set to a value that exceeds the actual allocated capacity. Subsequent APIs such as `spare_capacity_mut()` then trust this corrupted `cap` value and may create out-of-bounds slices, leading to UB.
     
     This behavior is observable in release builds (integer overflow wraps), whereas debug builds panic due to overflow checks.
     
     ## PoC
     
     ```rs
     use bytes::*;
     
     fn main() {
         let mut a = BytesMut::from(&b"hello world"[..]);
         let mut b = a.split_off(5);
     
         // Ensure b becomes the unique owner of the backing storage
         drop(a);
     
         // Trigger overflow in new_cap + offset inside reserve
         b.reserve(usize::MAX - 6);
     
         // This call relies on the corrupted cap and may cause UB & HBO
         b.put_u8(b'h');
     }
     ```
     
     # Workarounds
     
     Users of `BytesMut::reserve` are only affected if integer overflow checks are configured to wrap. When integer overflow is configured to panic, this issue does not apply.
   ├ Announcement: https://github.com/advisories/GHSA-434x-w66g-qw3r
   ├ Solution: Upgrade to >=1.11.1 (try `cargo update -p bytes`)
   ├ bytes v1.8.0
     ├── http v1.1.0
     │   ├── http-body v1.0.1
     │   │   ├── http-body-util v0.1.2
     │   │   │   ├── libdd-common v1.1.0
     │   │   │   │   └── libdd-telemetry v2.0.0
     │   │   │   └── libdd-telemetry v2.0.0 (*)
     │   │   ├── hyper v1.6.0
     │   │   │   ├── hyper-rustls v0.27.3
     │   │   │   │   └── libdd-common v1.1.0 (*)
     │   │   │   ├── hyper-util v0.1.17
     │   │   │   │   ├── hyper-rustls v0.27.3 (*)
     │   │   │   │   ├── libdd-common v1.1.0 (*)
     │   │   │   │   └── libdd-telemetry v2.0.0 (*)
     │   │   │   ├── libdd-common v1.1.0 (*)
     │   │   │   └── libdd-telemetry v2.0.0 (*)
     │   │   ├── hyper-util v0.1.17 (*)
     │   │   └── libdd-common v1.1.0 (*)
     │   ├── http-body-util v0.1.2 (*)
     │   ├── hyper v1.6.0 (*)
     │   ├── hyper-rustls v0.27.3 (*)
     │   ├── hyper-util v0.1.17 (*)
     │   ├── libdd-common v1.1.0 (*)
     │   └── libdd-telemetry v2.0.0 (*)
     ├── http-body v1.0.1 (*)
     ├── http-body-util v0.1.2 (*)
     ├── hyper v1.6.0 (*)
     ├── hyper-util v0.1.17 (*)
     ├── prost v0.14.3
     │   └── libdd-ddsketch v1.0.0
     │       └── libdd-telemetry v2.0.0 (*)
     ├── tokio v1.49.0
     │   ├── hyper v1.6.0 (*)
     │   ├── hyper-rustls v0.27.3 (*)
     │   ├── hyper-util v0.1.17 (*)
     │   ├── (dev) libdd-common v1.1.0 (*)
     │   ├── (dev) libdd-telemetry v2.0.0 (*)
     │   ├── tokio-rustls v0.26.0
     │   │   ├── hyper-rustls v0.27.3 (*)
     │   │   └── libdd-common v1.1.0 (*)
     │   └── tokio-util v0.7.12
     │       └── libdd-telemetry v2.0.0 (*)
     └── tokio-util v0.7.12 (*)

error[vulnerability]: Lenient `hyper` header parsing of `Content-Length` could allow request smuggling
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:64:1
   │
64 │ hyper 0.10.16 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2021-0078
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2021-0078
   ├ `hyper`'s HTTP header parser accepted, according to RFC 7230, illegal contents inside `Content-Length` headers.
     Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error.
     
     To be vulnerable, `hyper` must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents
     but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.
   ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-f3pg-qwvg-p99c
   ├ Solution: Upgrade to >=0.14.10 (try `cargo update -p hyper`)
   ├ hyper v0.10.16
     ├── iron v0.6.1
     │   └── multipart v0.18.0
     │       └── (dev) libdd-common v1.1.0
     │           └── libdd-telemetry v2.0.0
     ├── multipart v0.18.0 (*)
     └── nickel v0.11.0
         └── multipart v0.18.0 (*)

error[vulnerability]: Integer overflow in `hyper`'s parsing of the `Transfer-Encoding` header leads to data loss
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:64:1
   │
64 │ hyper 0.10.16 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2021-0079
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2021-0079
   ├ When decoding chunk sizes that are too large, `hyper`'s code would encounter an integer overflow. Depending on the situation,
     this could lead to data loss from an incorrect total size, or in rarer cases, a request smuggling attack.
     
     To be vulnerable, you must be using `hyper` for any HTTP/1 purpose, including as a client or server, and consumers must send
     requests or responses that specify a chunk size greater than 18 exabytes. For a possible request smuggling attack to be possible,
     any upstream proxies must accept a chunk size greater than 64 bits.
   ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-5h46-h7hh-c6x9
   ├ Solution: Upgrade to >=0.14.10 (try `cargo update -p hyper`)
   ├ hyper v0.10.16
     ├── iron v0.6.1
     │   └── multipart v0.18.0
     │       └── (dev) libdd-common v1.1.0
     │           └── libdd-telemetry v2.0.0
     ├── multipart v0.18.0 (*)
     └── nickel v0.11.0
         └── multipart v0.18.0 (*)

error[vulnerability]: `idna` accepts Punycode labels that do not produce any non-ASCII when decoded
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:70:1
   │
70 │ idna 0.1.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2024-0421
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0421
   ├ `idna` 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with `idna` 0.5.0 or earlier.
     
     Concretely, `example.org` and `xn--example-.org` become equal after processing by `idna` 0.5.0 or earlier. Also, `example.org.xn--` and `example.org.` become equal after processing by `idna` 0.5.0 or earlier.
     
     In applications using `idna` (but not in `idna` itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an `xn--`-masked name that turns into the name of the target when processed by `idna` 0.5.0 or earlier.
     
     ## Remedy
     
     Upgrade to `idna` 1.0.3 or later, if depending on `idna` directly, or to `url` 2.5.4 or later, if depending on `idna` via `url`. (This issue was fixed in `idna` 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)
     
     When upgrading, please take a moment to read about [alternative Unicode back ends for `idna`](https://docs.rs/crate/idna_adapter/latest).
     
     If you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an [issue](https://github.com/servo/rust-url/issues/992) about combining them with `url` 2.5.4 and `idna` 1.0.3.
     
     ## Additional information
     
     This issue resulted from `idna` 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in [revision 33 of UTS 46](https://www.unicode.org/reports/tr46/tr46-33.html#Modifications).
     
     ## Acknowledgements
     
     Thanks to kageshiron for recognizing the security implications of this behavior.
   ├ Announcement: https://bugzilla.mozilla.org/show_bug.cgi?id=1887898
   ├ Solution: Upgrade to >=1.0.0 (try `cargo update -p idna`)
   ├ idna v0.1.5
     └── url v1.7.2
         ├── hyper v0.10.16
         │   ├── iron v0.6.1
         │   │   └── multipart v0.18.0
         │   │       └── (dev) libdd-common v1.1.0
         │   │           └── libdd-telemetry v2.0.0
         │   ├── multipart v0.18.0 (*)
         │   └── nickel v0.11.0
         │       └── multipart v0.18.0 (*)
         ├── iron v0.6.1 (*)
         ├── nickel v0.11.0 (*)
         └── tiny_http v0.6.4
             └── multipart v0.18.0 (*)

error[unmaintained]: multipart is Unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:99:1
   │
99 │ multipart 0.18.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2023-0050
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2023-0050
   ├ The `multipart` crate is unmaintained. The author has archived the github
     repository.
     
     Alternatives:
     
     - [multer](https://crates.io/crates/multer)
     - [multiparty](https://crates.io/crates/multiparty)
   ├ Solution: No safe upgrade is available!
   ├ multipart v0.18.0
     └── (dev) libdd-common v1.1.0
         └── libdd-telemetry v2.0.0

error[vulnerability]: Potential segfault in the time crate
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:177:1
    │
177 │ time 0.1.45 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2020-0071
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2020-0071
    ├ ### Impact
      
      The affected functions set environment variables without synchronization. On Unix-like operating systems, this can crash in multithreaded programs. Programs may segfault due to dereferencing a dangling pointer if an environment variable is read in a different thread than the affected functions. This may occur without the user's knowledge, notably in the Rust standard library or third-party libraries.
      
      The affected functions from time 0.2.7 through 0.2.22 are:
      
      - `time::UtcOffset::local_offset_at`
      - `time::UtcOffset::try_local_offset_at`
      - `time::UtcOffset::current_local_offset`
      - `time::UtcOffset::try_current_local_offset`
      - `time::OffsetDateTime::now_local`
      - `time::OffsetDateTime::try_now_local`
      
      The affected functions in time 0.1 (all versions) are:
      
      - `time::at_utc`
      - `time::at`
      - `time::now`
      - `time::tzset`
      
      Non-Unix targets (including Windows and wasm) are unaffected.
      
      ### Patches
      
      Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods.
      
      Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code.
      
      Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.
      
      ### Workarounds
      
      A possible workaround for crates affected through the transitive dependency in `chrono`, is to avoid using the default `oldtime` feature dependency of the `chrono` crate by disabling its `default-features` and manually specifying the required features instead.
      
      #### Examples:
      
      `Cargo.toml`:  
      
      ```toml
      chrono = { version = "0.4", default-features = false, features = ["serde"] }
      ```
      
      ```toml
      chrono = { version = "0.4.22", default-features = false, features = ["clock"] }
      ```
      
      Commandline:  
      
      ```bash
      cargo add chrono --no-default-features -F clock
      ```
      
      Sources:  
       - [chronotope/chrono#602 (comment)](https://github.com/chronotope/chrono/issues/602#issuecomment-1242149249)  
       - [vityafx/serde-aux#21](https://github.com/vityafx/serde-aux/issues/21)
    ├ Announcement: https://github.com/time-rs/time/issues/293
    ├ Solution: Upgrade to >=0.2.23 (try `cargo update -p time`)
    ├ time v0.1.45
      ├── hyper v0.10.16
      │   ├── iron v0.6.1
      │   │   └── multipart v0.18.0
      │   │       └── (dev) libdd-common v1.1.0
      │   │           └── libdd-telemetry v2.0.0
      │   ├── multipart v0.18.0 (*)
      │   └── nickel v0.11.0
      │       └── multipart v0.18.0 (*)
      └── nickel v0.11.0 (*)

error[vulnerability]: Logging user input may result in poisoning logs with ANSI escape sequences
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:189:1
    │
189 │ tracing-subscriber 0.3.19 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2025-0055
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0055
    ├ Previous versions of tracing-subscriber were vulnerable to ANSI escape sequence injection attacks. Untrusted user input containing ANSI escape sequences could be injected into terminal output when logged, potentially allowing attackers to:
      
      - Manipulate terminal title bars
      - Clear screens or modify terminal display
      - Potentially mislead users through terminal manipulation
      
      In isolation, impact is minimal, however security issues have been found in terminal emulators that enabled an attacker to use ANSI escape sequences via logs to exploit vulnerabilities in the terminal emulator.
      
      This was patched in [PR #3368](https://github.com/tokio-rs/tracing/pull/3368) to escape ANSI control characters from user input.
    ├ Announcement: https://github.com/advisories/GHSA-xwfj-jgwm-7wp5
    ├ Solution: Upgrade to >=0.3.20 (try `cargo update -p tracing-subscriber`)
    ├ tracing-subscriber v0.3.19
      └── (dev) libdd-telemetry v2.0.0

advisories FAILED, bans ok, sources ok

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

Show output

error[vulnerability]: Integer overflow in `BytesMut::reserve`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:49:1
   │
49 │ bytes 1.8.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0007
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0007
   ├ In the unique reclaim path of `BytesMut::reserve`, the condition
     ```rs
     if v_capacity >= new_cap + offset
     ```
     uses an unchecked addition. When `new_cap + offset` overflows `usize` in release builds, this condition may incorrectly pass, causing `self.cap` to be set to a value that exceeds the actual allocated capacity. Subsequent APIs such as `spare_capacity_mut()` then trust this corrupted `cap` value and may create out-of-bounds slices, leading to UB.
     
     This behavior is observable in release builds (integer overflow wraps), whereas debug builds panic due to overflow checks.
     
     ## PoC
     
     ```rs
     use bytes::*;
     
     fn main() {
         let mut a = BytesMut::from(&b"hello world"[..]);
         let mut b = a.split_off(5);
     
         // Ensure b becomes the unique owner of the backing storage
         drop(a);
     
         // Trigger overflow in new_cap + offset inside reserve
         b.reserve(usize::MAX - 6);
     
         // This call relies on the corrupted cap and may cause UB & HBO
         b.put_u8(b'h');
     }
     ```
     
     # Workarounds
     
     Users of `BytesMut::reserve` are only affected if integer overflow checks are configured to wrap. When integer overflow is configured to panic, this issue does not apply.
   ├ Announcement: https://github.com/advisories/GHSA-434x-w66g-qw3r
   ├ Solution: Upgrade to >=1.11.1 (try `cargo update -p bytes`)
   ├ bytes v1.8.0
     ├── h2 v0.4.6
     │   └── hyper v1.6.0
     │       ├── httpmock v0.8.0-alpha.1
     │       │   └── libdd-trace-utils v1.0.0
     │       │       └── (dev) libdd-trace-utils v1.0.0 (*)
     │       ├── hyper-rustls v0.27.3
     │       │   └── libdd-common v1.1.0
     │       │       └── libdd-trace-utils v1.0.0 (*)
     │       ├── hyper-util v0.1.17
     │       │   ├── httpmock v0.8.0-alpha.1 (*)
     │       │   ├── hyper-rustls v0.27.3 (*)
     │       │   └── libdd-common v1.1.0 (*)
     │       ├── libdd-common v1.1.0 (*)
     │       └── libdd-trace-utils v1.0.0 (*)
     ├── headers v0.4.0
     │   └── httpmock v0.8.0-alpha.1 (*)
     ├── http v1.1.0
     │   ├── h2 v0.4.6 (*)
     │   ├── headers v0.4.0 (*)
     │   ├── headers-core v0.3.0
     │   │   └── headers v0.4.0 (*)
     │   ├── http-body v1.0.1
     │   │   ├── http-body-util v0.1.2
     │   │   │   ├── httpmock v0.8.0-alpha.1 (*)
     │   │   │   ├── libdd-common v1.1.0 (*)
     │   │   │   └── libdd-trace-utils v1.0.0 (*)
     │   │   ├── hyper v1.6.0 (*)
     │   │   ├── hyper-util v0.1.17 (*)
     │   │   └── libdd-common v1.1.0 (*)
     │   ├── http-body-util v0.1.2 (*)
     │   ├── httpmock v0.8.0-alpha.1 (*)
     │   ├── hyper v1.6.0 (*)
     │   ├── hyper-rustls v0.27.3 (*)
     │   ├── hyper-util v0.1.17 (*)
     │   ├── libdd-common v1.1.0 (*)
     │   └── libdd-trace-utils v1.0.0 (*)
     ├── http-body v1.0.1 (*)
     ├── http-body-util v0.1.2 (*)
     ├── httpmock v0.8.0-alpha.1 (*)
     ├── hyper v1.6.0 (*)
     ├── hyper-util v0.1.17 (*)
     ├── libdd-trace-utils v1.0.0 (*)
     ├── prost v0.14.3
     │   ├── libdd-trace-protobuf v1.0.0
     │   │   ├── libdd-trace-normalization v1.0.0
     │   │   │   └── libdd-trace-utils v1.0.0 (*)
     │   │   └── libdd-trace-utils v1.0.0 (*)
     │   └── libdd-trace-utils v1.0.0 (*)
     ├── tokio v1.49.0
     │   ├── h2 v0.4.6 (*)
     │   ├── httpmock v0.8.0-alpha.1 (*)
     │   ├── hyper v1.6.0 (*)
     │   ├── hyper-rustls v0.27.3 (*)
     │   ├── hyper-util v0.1.17 (*)
     │   ├── (dev) libdd-common v1.1.0 (*)
     │   ├── (dev) libdd-trace-protobuf v1.0.0 (*)
     │   ├── (dev) libdd-trace-utils v1.0.0 (*)
     │   ├── tokio-rustls v0.26.0
     │   │   ├── hyper-rustls v0.27.3 (*)
     │   │   └── libdd-common v1.1.0 (*)
     │   └── tokio-util v0.7.12
     │       └── h2 v0.4.6 (*)
     └── tokio-util v0.7.12 (*)

error[vulnerability]: Lenient `hyper` header parsing of `Content-Length` could allow request smuggling
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:132:1
    │
132 │ hyper 0.10.16 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2021-0078
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2021-0078
    ├ `hyper`'s HTTP header parser accepted, according to RFC 7230, illegal contents inside `Content-Length` headers.
      Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error.
      
      To be vulnerable, `hyper` must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents
      but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-f3pg-qwvg-p99c
    ├ Solution: Upgrade to >=0.14.10 (try `cargo update -p hyper`)
    ├ hyper v0.10.16
      ├── iron v0.6.1
      │   └── multipart v0.18.0
      │       └── (dev) libdd-common v1.1.0
      │           └── libdd-trace-utils v1.0.0
      │               └── (dev) libdd-trace-utils v1.0.0 (*)
      ├── multipart v0.18.0 (*)
      └── nickel v0.11.0
          └── multipart v0.18.0 (*)

error[vulnerability]: Integer overflow in `hyper`'s parsing of the `Transfer-Encoding` header leads to data loss
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:132:1
    │
132 │ hyper 0.10.16 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2021-0079
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2021-0079
    ├ When decoding chunk sizes that are too large, `hyper`'s code would encounter an integer overflow. Depending on the situation,
      this could lead to data loss from an incorrect total size, or in rarer cases, a request smuggling attack.
      
      To be vulnerable, you must be using `hyper` for any HTTP/1 purpose, including as a client or server, and consumers must send
      requests or responses that specify a chunk size greater than 18 exabytes. For a possible request smuggling attack to be possible,
      any upstream proxies must accept a chunk size greater than 64 bits.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-5h46-h7hh-c6x9
    ├ Solution: Upgrade to >=0.14.10 (try `cargo update -p hyper`)
    ├ hyper v0.10.16
      ├── iron v0.6.1
      │   └── multipart v0.18.0
      │       └── (dev) libdd-common v1.1.0
      │           └── libdd-trace-utils v1.0.0
      │               └── (dev) libdd-trace-utils v1.0.0 (*)
      ├── multipart v0.18.0 (*)
      └── nickel v0.11.0
          └── multipart v0.18.0 (*)

error[vulnerability]: `idna` accepts Punycode labels that do not produce any non-ASCII when decoded
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:148:1
    │
148 │ idna 0.1.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2024-0421
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0421
    ├ `idna` 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with `idna` 0.5.0 or earlier.
      
      Concretely, `example.org` and `xn--example-.org` become equal after processing by `idna` 0.5.0 or earlier. Also, `example.org.xn--` and `example.org.` become equal after processing by `idna` 0.5.0 or earlier.
      
      In applications using `idna` (but not in `idna` itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an `xn--`-masked name that turns into the name of the target when processed by `idna` 0.5.0 or earlier.
      
      ## Remedy
      
      Upgrade to `idna` 1.0.3 or later, if depending on `idna` directly, or to `url` 2.5.4 or later, if depending on `idna` via `url`. (This issue was fixed in `idna` 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)
      
      When upgrading, please take a moment to read about [alternative Unicode back ends for `idna`](https://docs.rs/crate/idna_adapter/latest).
      
      If you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an [issue](https://github.com/servo/rust-url/issues/992) about combining them with `url` 2.5.4 and `idna` 1.0.3.
      
      ## Additional information
      
      This issue resulted from `idna` 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in [revision 33 of UTS 46](https://www.unicode.org/reports/tr46/tr46-33.html#Modifications).
      
      ## Acknowledgements
      
      Thanks to kageshiron for recognizing the security implications of this behavior.
    ├ Announcement: https://bugzilla.mozilla.org/show_bug.cgi?id=1887898
    ├ Solution: Upgrade to >=1.0.0 (try `cargo update -p idna`)
    ├ idna v0.1.5
      └── url v1.7.2
          ├── hyper v0.10.16
          │   ├── iron v0.6.1
          │   │   └── multipart v0.18.0
          │   │       └── (dev) libdd-common v1.1.0
          │   │           └── libdd-trace-utils v1.0.0
          │   │               └── (dev) libdd-trace-utils v1.0.0 (*)
          │   ├── multipart v0.18.0 (*)
          │   └── nickel v0.11.0
          │       └── multipart v0.18.0 (*)
          ├── iron v0.6.1 (*)
          ├── nickel v0.11.0 (*)
          └── tiny_http v0.6.4
              └── multipart v0.18.0 (*)

error[unmaintained]: multipart is Unmaintained
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:186:1
    │
186 │ multipart 0.18.0 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
    │
    ├ ID: RUSTSEC-2023-0050
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2023-0050
    ├ The `multipart` crate is unmaintained. The author has archived the github
      repository.
      
      Alternatives:
      
      - [multer](https://crates.io/crates/multer)
      - [multiparty](https://crates.io/crates/multiparty)
    ├ Solution: No safe upgrade is available!
    ├ multipart v0.18.0
      └── (dev) libdd-common v1.1.0
          └── libdd-trace-utils v1.0.0
              └── (dev) libdd-trace-utils v1.0.0 (*)

error[vulnerability]: Potential segfault in the time crate
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:301:1
    │
301 │ time 0.1.45 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2020-0071
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2020-0071
    ├ ### Impact
      
      The affected functions set environment variables without synchronization. On Unix-like operating systems, this can crash in multithreaded programs. Programs may segfault due to dereferencing a dangling pointer if an environment variable is read in a different thread than the affected functions. This may occur without the user's knowledge, notably in the Rust standard library or third-party libraries.
      
      The affected functions from time 0.2.7 through 0.2.22 are:
      
      - `time::UtcOffset::local_offset_at`
      - `time::UtcOffset::try_local_offset_at`
      - `time::UtcOffset::current_local_offset`
      - `time::UtcOffset::try_current_local_offset`
      - `time::OffsetDateTime::now_local`
      - `time::OffsetDateTime::try_now_local`
      
      The affected functions in time 0.1 (all versions) are:
      
      - `time::at_utc`
      - `time::at`
      - `time::now`
      - `time::tzset`
      
      Non-Unix targets (including Windows and wasm) are unaffected.
      
      ### Patches
      
      Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods.
      
      Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code.
      
      Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.
      
      ### Workarounds
      
      A possible workaround for crates affected through the transitive dependency in `chrono`, is to avoid using the default `oldtime` feature dependency of the `chrono` crate by disabling its `default-features` and manually specifying the required features instead.
      
      #### Examples:
      
      `Cargo.toml`:  
      
      ```toml
      chrono = { version = "0.4", default-features = false, features = ["serde"] }
      ```
      
      ```toml
      chrono = { version = "0.4.22", default-features = false, features = ["clock"] }
      ```
      
      Commandline:  
      
      ```bash
      cargo add chrono --no-default-features -F clock
      ```
      
      Sources:  
       - [chronotope/chrono#602 (comment)](https://github.com/chronotope/chrono/issues/602#issuecomment-1242149249)  
       - [vityafx/serde-aux#21](https://github.com/vityafx/serde-aux/issues/21)
    ├ Announcement: https://github.com/time-rs/time/issues/...*[Comment body truncated]*

[pr-commenter]

Benchmarks

Comparison

Benchmark execution time: 2026-02-10 13:28:14

Comparing candidate commit 7e5584e in PR branch jwiriath/get-random-js-feature-for-wasm with baseline commit b4fe491 in branch main.

Found 0 performance improvements and 12 performance regressions! Performance is the same for 45 metrics, 2 unstable metrics.

scenario:credit_card/is_card_number/ 378282246310005

• 🟥 execution_time [+3.982µs; +4.086µs] or [+5.614%; +5.761%]
• 🟥 throughput [-768810.751op/s; -748847.385op/s] or [-5.453%; -5.312%]

scenario:credit_card/is_card_number/378282246310005

• 🟥 execution_time [+4.310µs; +4.416µs] or [+6.366%; +6.521%]
• 🟥 throughput [-905316.059op/s; -883172.275op/s] or [-6.130%; -5.980%]

scenario:credit_card/is_card_number/37828224631000521389798

• 🟥 execution_time [+6.954µs; +6.994µs] or [+15.375%; +15.465%]
• 🟥 throughput [-2964022.039op/s; -2944377.037op/s] or [-13.405%; -13.316%]

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

• 🟥 execution_time [+4.509µs; +4.540µs] or [+8.505%; +8.564%]
• 🟥 throughput [-1488085.459op/s; -1478539.293op/s] or [-7.888%; -7.838%]

scenario:credit_card/is_card_number_no_luhn/378282246310005

• 🟥 execution_time [+4.935µs; +4.974µs] or [+9.910%; +9.987%]
• 🟥 throughput [-1823255.836op/s; -1810400.560op/s] or [-9.080%; -9.016%]

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

• 🟥 execution_time [+7.015µs; +7.057µs] or [+15.527%; +15.621%]
• 🟥 throughput [-2993204.018op/s; -2972845.543op/s] or [-13.522%; -13.430%]

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	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
redis/obfuscate_redis_string	execution_time	33.945µs	34.607µs ± 1.162µs	34.083µs ± 0.059µs	34.154µs	37.117µs	37.139µs	37.900µs	11.20%	1.703	0.955	3.35%	0.082µs	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
redis/obfuscate_redis_string	execution_time	[34.446µs; 34.768µs] or [-0.465%; +0.465%]	None	None	None

Group 2

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

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	18.149µs	26.202µs ± 10.009µs	18.356µs ± 0.132µs	34.052µs	44.123µs	53.281µs	79.110µs	330.99%	1.292	2.842	38.10%	0.708µs	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
two way interface	execution_time	[24.814µs; 27.589µs] or [-5.294%; +5.294%]	None	None	None

Group 3

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
profile_add_sample_frames_x1000	execution_time	3.942ms	3.945ms ± 0.007ms	3.944ms ± 0.001ms	3.946ms	3.950ms	3.954ms	4.033ms	2.26%	11.583	149.349	0.17%	0.000ms	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
profile_add_sample_frames_x1000	execution_time	[3.944ms; 3.946ms] or [-0.023%; +0.023%]	None	None	None

Group 4

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
ip_address/quantize_peer_ip_address_benchmark	execution_time	5.009µs	5.091µs ± 0.062µs	5.057µs ± 0.015µs	5.119µs	5.217µs	5.221µs	5.222µs	3.26%	1.026	-0.437	1.21%	0.004µs	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
ip_address/quantize_peer_ip_address_benchmark	execution_time	[5.083µs; 5.100µs] or [-0.168%; +0.168%]	None	None	None

Group 5

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...	execution_time	534.960µs	537.110µs ± 1.285µs	536.643µs ± 0.598µs	537.839µs	539.325µs	541.354µs	542.522µs	1.10%	1.310	2.142	0.24%	0.091µs	1	200
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...	throughput	1843243.823op/s	1861828.284op/s ± 4442.071op/s	1863437.746op/s ± 2077.705op/s	1864837.510op/s	1866874.374op/s	1868341.246op/s	1869297.200op/s	0.31%	-1.292	2.066	0.24%	314.102op/s	1	200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	execution_time	381.639µs	382.183µs ± 0.269µs	382.123µs ± 0.171µs	382.335µs	382.634µs	382.940µs	383.233µs	0.29%	0.930	1.332	0.07%	0.019µs	1	200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	throughput	2609375.372op/s	2616551.423op/s ± 1838.047op/s	2616958.563op/s ± 1171.084op/s	2617847.305op/s	2618820.975op/s	2619792.829op/s	2620277.278op/s	0.13%	-0.925	1.316	0.07%	129.970op/s	1	200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	execution_time	189.279µs	189.608µs ± 0.152µs	189.601µs ± 0.112µs	189.708µs	189.878µs	189.935µs	190.069µs	0.25%	0.366	-0.377	0.08%	0.011µs	1	200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	throughput	5261238.714op/s	5274029.365op/s ± 4231.344op/s	5274242.345op/s ± 3102.337op/s	5277416.356op/s	5280166.373op/s	5281285.337op/s	5283208.419op/s	0.17%	-0.363	-0.381	0.08%	299.201op/s	1	200
normalization/normalize_service/normalize_service/[empty string]	execution_time	36.479µs	36.661µs ± 0.103µs	36.641µs ± 0.041µs	36.697µs	36.787µs	36.880µs	37.749µs	3.03%	6.104	59.943	0.28%	0.007µs	1	200
normalization/normalize_service/normalize_service/[empty string]	throughput	26490587.276op/s	27277139.743op/s ± 75600.110op/s	27292032.263op/s ± 30944.300op/s	27317962.893op/s	27342255.083op/s	27359139.184op/s	27412694.671op/s	0.44%	-5.900	57.014	0.28%	5345.735op/s	1	200
normalization/normalize_service/normalize_service/test_ASCII	execution_time	45.979µs	46.097µs ± 0.108µs	46.088µs ± 0.036µs	46.124µs	46.175µs	46.220µs	47.446µs	2.95%	9.875	121.098	0.23%	0.008µs	1	200
normalization/normalize_service/normalize_service/test_ASCII	throughput	21076621.951op/s	21693362.305op/s ± 49574.805op/s	21697645.492op/s ± 16736.676op/s	21714020.321op/s	21731772.340op/s	21745366.628op/s	21749017.307op/s	0.24%	-9.696	118.124	0.23%	3505.468op/s	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...	execution_time	[536.931µs; 537.288µs] or [-0.033%; +0.033%]	None	None	None
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...	throughput	[1861212.655op/s; 1862443.912op/s] or [-0.033%; +0.033%]	None	None	None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	execution_time	[382.145µs; 382.220µs] or [-0.010%; +0.010%]	None	None	None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	throughput	[2616296.687op/s; 2616806.159op/s] or [-0.010%; +0.010%]	None	None	None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	execution_time	[189.587µs; 189.630µs] or [-0.011%; +0.011%]	None	None	None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	throughput	[5273442.941op/s; 5274615.789op/s] or [-0.011%; +0.011%]	None	None	None
normalization/normalize_service/normalize_service/[empty string]	execution_time	[36.647µs; 36.675µs] or [-0.039%; +0.039%]	None	None	None
normalization/normalize_service/normalize_service/[empty string]	throughput	[27266662.295op/s; 27287617.191op/s] or [-0.038%; +0.038%]	None	None	None
normalization/normalize_service/normalize_service/test_ASCII	execution_time	[46.082µs; 46.112µs] or [-0.032%; +0.032%]	None	None	None
normalization/normalize_service/normalize_service/test_ASCII	throughput	[21686491.714op/s; 21700232.896op/s] or [-0.032%; +0.032%]	None	None	None

Group 6

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
tags/replace_trace_tags	execution_time	2.390µs	2.420µs ± 0.032µs	2.412µs ± 0.008µs	2.423µs	2.464µs	2.589µs	2.593µs	7.53%	3.988	17.916	1.30%	0.002µs	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
tags/replace_trace_tags	execution_time	[2.416µs; 2.425µs] or [-0.181%; +0.181%]	None	None	None

Group 7

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
benching deserializing traces from msgpack to their internal representation	execution_time	48.249ms	48.582ms ± 1.139ms	48.392ms ± 0.066ms	48.529ms	48.673ms	56.287ms	59.682ms	23.33%	7.931	64.845	2.34%	0.081ms	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
benching deserializing traces from msgpack to their internal representation	execution_time	[48.424ms; 48.740ms] or [-0.325%; +0.325%]	None	None	None

Group 8

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
sdk_test_data/rules-based	execution_time	143.876µs	145.720µs ± 1.882µs	145.349µs ± 0.572µs	146.069µs	147.365µs	152.186µs	164.296µs	13.04%	6.196	51.842	1.29%	0.133µs	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
sdk_test_data/rules-based	execution_time	[145.459µs; 145.981µs] or [-0.179%; +0.179%]	None	None	None

Group 9

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
benching serializing traces from their internal representation to msgpack	execution_time	14.452ms	14.524ms ± 0.044ms	14.519ms ± 0.015ms	14.533ms	14.571ms	14.697ms	14.885ms	2.52%	3.896	24.334	0.30%	0.003ms	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
benching serializing traces from their internal representation to msgpack	execution_time	[14.518ms; 14.530ms] or [-0.042%; +0.042%]	None	None	None

Group 10

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
sql/obfuscate_sql_string	execution_time	85.703µs	85.915µs ± 0.221µs	85.873µs ± 0.059µs	85.940µs	86.107µs	86.869µs	88.008µs	2.49%	5.644	43.142	0.26%	0.016µs	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
sql/obfuscate_sql_string	execution_time	[85.884µs; 85.945µs] or [-0.036%; +0.036%]	None	None	None

Group 11

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

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.218µs	3.223µs ± 1.404µs	3.019µs ± 0.024µs	3.038µs	3.669µs	13.824µs	14.805µs	390.31%	7.321	54.926	43.46%	0.099µs	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
write only interface	execution_time	[3.029µs; 3.418µs] or [-6.038%; +6.038%]	None	None	None

Group 12

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

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/2597	execution_time	9.688ms	10.048ms ± 0.074ms	10.050ms ± 0.031ms	10.082ms	10.167ms	10.220ms	10.249ms	1.98%	-1.422	6.372	0.74%	0.005ms	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
receiver_entry_point/report/2597	execution_time	[10.037ms; 10.058ms] or [-0.103%; +0.103%]	None	None	None

Group 13

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...	execution_time	204.940µs	205.657µs ± 0.451µs	205.575µs ± 0.309µs	205.945µs	206.436µs	207.061µs	207.316µs	0.85%	0.812	0.775	0.22%	0.032µs	1	200
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...	throughput	4823544.320op/s	4862477.304op/s ± 10648.469op/s	4864396.085op/s ± 7316.869op/s	4870345.320op/s	4876666.374op/s	4878888.735op/s	4879484.642op/s	0.31%	-0.798	0.732	0.22%	752.960op/s	1	200
normalization/normalize_name/normalize_name/bad-name	execution_time	18.554µs	18.624µs ± 0.056µs	18.614µs ± 0.023µs	18.640µs	18.687µs	18.763µs	19.173µs	3.00%	5.784	49.984	0.30%	0.004µs	1	200
normalization/normalize_name/normalize_name/bad-name	throughput	52157024.468op/s	53695473.294op/s ± 157961.686op/s	53721903.558op/s ± 66510.151op/s	53783663.646op/s	53834076.627op/s	53874382.375op/s	53895921.495op/s	0.32%	-5.621	47.815	0.29%	11169.578op/s	1	200
normalization/normalize_name/normalize_name/good	execution_time	10.791µs	10.874µs ± 0.033µs	10.869µs ± 0.020µs	10.893µs	10.923µs	10.976µs	11.004µs	1.25%	0.717	1.444	0.30%	0.002µs	1	200
normalization/normalize_name/normalize_name/good	throughput	90872325.770op/s	91965991.459op/s ± 278614.468op/s	92008823.030op/s ± 168878.725op/s	92150792.602op/s	92372333.440op/s	92483708.578op/s	92670997.444op/s	0.72%	-0.690	1.377	0.30%	19701.018op/s	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...	execution_time	[205.595µs; 205.720µs] or [-0.030%; +0.030%]	None	None	None
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...	throughput	[4861001.528op/s; 4863953.079op/s] or [-0.030%; +0.030%]	None	None	None
normalization/normalize_name/normalize_name/bad-name	execution_time	[18.616µs; 18.631µs] or [-0.041%; +0.041%]	None	None	None
normalization/normalize_name/normalize_name/bad-name	throughput	[53673581.324op/s; 53717365.265op/s] or [-0.041%; +0.041%]	None	None	None
normalization/normalize_name/normalize_name/good	execution_time	[10.869µs; 10.878µs] or [-0.042%; +0.042%]	None	None	None
normalization/normalize_name/normalize_name/good	throughput	[91927378.173op/s; 92004604.744op/s] or [-0.042%; +0.042%]	None	None	None

Group 14

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
credit_card/is_card_number/	execution_time	3.891µs	3.911µs ± 0.003µs	3.911µs ± 0.001µs	3.912µs	3.917µs	3.919µs	3.929µs	0.48%	0.387	10.589	0.08%	0.000µs	1	200
credit_card/is_card_number/	throughput	254490331.109op/s	255673832.982op/s ± 213743.976op/s	255700805.458op/s ± 86691.790op/s	255784338.521op/s	255884890.919op/s	256013856.905op/s	256972140.582op/s	0.50%	-0.356	10.643	0.08%	15113.981op/s	1	200
credit_card/is_card_number/ 3782-8224-6310-005	execution_time	78.851µs	80.262µs ± 0.614µs	80.259µs ± 0.436µs	80.658µs	81.305µs	81.759µs	81.775µs	1.89%	0.222	-0.435	0.76%	0.043µs	1	200
credit_card/is_card_number/ 3782-8224-6310-005	throughput	12228742.044op/s	12459851.067op/s ± 95103.732op/s	12459609.700op/s ± 67281.066op/s	12533110.448op/s	12595175.746op/s	12646125.885op/s	12682131.901op/s	1.79%	-0.187	-0.456	0.76%	6724.849op/s	1	200
credit_card/is_card_number/ 378282246310005	execution_time	74.377µs	74.967µs ± 0.209µs	74.949µs ± 0.093µs	75.064µs	75.359µs	75.523µs	75.832µs	1.18%	0.527	2.205	0.28%	0.015µs	1	200
credit_card/is_card_number/ 378282246310005	throughput	13186999.626op/s	13339368.645op/s ± 37099.428op/s	13342321.148op/s ± 16568.839op/s	13356694.597op/s	13401120.046op/s	13421068.827op/s	13445080.009op/s	0.77%	-0.495	2.142	0.28%	2623.326op/s	1	200
credit_card/is_card_number/37828224631	execution_time	3.891µs	3.911µs ± 0.003µs	3.910µs ± 0.001µs	3.912µs	3.915µs	3.917µs	3.919µs	0.23%	-1.359	14.517	0.07%	0.000µs	1	200
credit_card/is_card_number/37828224631	throughput	255152957.615op/s	255699170.009op/s ± 174747.599op/s	255729738.267op/s ± 79534.820op/s	255796783.356op/s	255880851.961op/s	255938658.399op/s	257001094.616op/s	0.50%	1.389	14.749	0.07%	12356.521op/s	1	200
credit_card/is_card_number/378282246310005	execution_time	71.435µs	72.076µs ± 0.182µs	72.074µs ± 0.098µs	72.176µs	72.365µs	72.514µs	72.664µs	0.82%	-0.087	1.289	0.25%	0.013µs	1	200
credit_card/is_card_number/378282246310005	throughput	13762028.780op/s	13874264.694op/s ± 35053.191op/s	13874676.643op/s ± 18824.672op/s	13892485.223op/s	13931458.211op/s	13975360.694op/s	13998738.704op/s	0.89%	0.112	1.302	0.25%	2478.635op/s	1	200
credit_card/is_card_number/37828224631000521389798	execution_time	52.131µs	52.201µs ± 0.034µs	52.194µs ± 0.020µs	52.220µs	52.270µs	52.294µs	52.308µs	0.22%	0.828	0.348	0.07%	0.002µs	1	200
credit_card/is_card_number/37828224631000521389798	throughput	19117637.395op/s	19156788.950op/s ± 12589.661op/s	19159232.028op/s ± 7402.662op/s	19165744.586op/s	19172927.252op/s	19177870.279op/s	19182338.821op/s	0.12%	-0.824	0.342	0.07%	890.223op/s	1	200
credit_card/is_card_number/x371413321323331	execution_time	6.018µs	6.046µs ± 0.009µs	6.047µs ± 0.006µs	6.052µs	6.060µs	6.064µs	6.073µs	0.43%	-0.102	0.066	0.15%	0.001µs	1	200
credit_card/is_card_number/x371413321323331	throughput	164665487.163op/s	165393058.018op/s ± 240855.579op/s	165378971.034op/s ± 159179.730op/s	165544278.123op/s	165782249.440op/s	165915867.086op/s	166175395.336op/s	0.48%	0.111	0.068	0.15%	17031.061op/s	1	200
credit_card/is_card_number_no_luhn/	execution_time	3.889µs	3.912µs ± 0.004µs	3.911µs ± 0.002µs	3.914µs	3.917µs	3.919µs	3.929µs	0.44%	-0.439	7.892	0.09%	0.000µs	1	200
credit_card/is_card_number_no_luhn/	throughput	254546269.036op/s	255648493.717op/s ± 239413.897op/s	255668949.010op/s ± 159554.448op/s	255803664.435op/s	255928539.081op/s	255989548.251op/s	257127779.132op/s	0.57%	0.466	7.994	0.09%	16929.119op/s	1	200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	execution_time	64.081µs	64.310µs ± 0.110µs	64.280µs ± 0.048µs	64.352µs	64.503µs	64.710µs	64.783µs	0.78%	1.795	4.275	0.17%	0.008µs	1	200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	throughput	15436220.160op/s	15549755.030op/s ± 26551.468op/s	15556861.601op/s ± 11624.669op/s	15566625.544op/s	15578319.110op/s	15585717.204op/s	15605193.408op/s	0.31%	-1.779	4.206	0.17%	1877.472op/s	1	200
credit_card/is_card_number_no_luhn/ 378282246310005	execution_time	57.371µs	57.535µs ± 0.106µs	57.519µs ± 0.061µs	57.580µs	57.741µs	57.854µs	57.927µs	0.71%	1.167	1.398	0.18%	0.007µs	1	200
credit_card/is_card_number_no_luhn/ 378282246310005	throughput	17263119.003op/s	17380915.098op/s ± 31820.257op/s	17385707.211op/s ± 18366.712op/s	17403438.484op/s	17420380.801op/s	17426353.719op/s	17430540.049op/s	0.26%	-1.155	1.363	0.18%	2250.032op/s	1	200
credit_card/is_card_number_no_luhn/37828224631	execution_time	3.889µs	3.911µs ± 0.003µs	3.911µs ± 0.001µs	3.912µs	3.915µs	3.918µs	3.918µs	0.18%	-2.220	20.478	0.07%	0.000µs	1	200
credit_card/is_card_number_no_luhn/37828224631	throughput	255233356.854op/s	255690805.688op/s ± 175262.080op/s	255690488.316op/s ± 96341.184op/s	255797401.256op/s	255887569.432op/s	255975527.817op/s	257115859.906op/s	0.56%	2.256	20.807	0.07%	12392.901op/s	1	200
credit_card/is_card_number_no_luhn/378282246310005	execution_time	54.567µs	54.756µs ± 0.136µs	54.720µs ± 0.071µs	54.817µs	55.074µs	55.180µs	55.341µs	1.13%	1.554	2.757	0.25%	0.010µs	1	200
credit_card/is_card_number_no_luhn/378282246310005	throughput	18069896.136op/s	18262954.766op/s ± 45229.622op/s	18274732.446op/s ± 23695.719op/s	18294452.676op/s	18311274.163op/s	18323830.747op/s	18326213.816op/s	0.28%	-1.536	2.687	0.25%	3198.217op/s	1	200
credit_card/is_card_number_no_luhn/37828224631000521389798	execution_time	52.139µs	52.213µs ± 0.051µs	52.204µs ± 0.029µs	52.236µs	52.309µs	52.372µs	52.434µs	0.44%	1.357	2.516	0.10%	0.004µs	1	200
credit_card/is_card_number_no_luhn/37828224631000521389798	throughput	19071655.388op/s	19152282.696op/s ± 18572.670op/s	19155608.793op/s ± 10711.858op/s	19165513.097op/s	19174003.407op/s	19178966.447op/s	19179527.772op/s	0.12%	-1.349	2.484	0.10%	1313.286op/s	1	200
credit_card/is_card_number_no_luhn/x371413321323331	execution_time	6.026µs	6.047µs ± 0.009µs	6.047µs ± 0.006µs	6.052µs	6.062µs	6.067µs	6.074µs	0.46%	0.122	-0.003	0.15%	0.001µs	1	200
credit_card/is_card_number_no_luhn/x371413321323331	throughput	164628604.780op/s	165380907.695op/s ± 248881.904op/s	165383874.203op/s ± 160332.418op/s	165546904.066op/s	165835776.477op/s	165909484.672op/s	165947544.285op/s	0.34%	-0.113	-0.007	0.15%	17598.608op/s	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
credit_card/is_card_number/	execution_time	[3.911µs; 3.912µs] or [-0.012%; +0.012%]	None	None	None
credit_card/is_card_number/	throughput	[255644210.123op/s; 255703455.842op/s] or [-0.012%; +0.012%]	None	None	None
credit_card/is_card_number/ 3782-8224-6310-005	execution_time	[80.177µs; 80.347µs] or [-0.106%; +0.106%]	None	None	None
credit_card/is_card_number/ 3782-8224-6310-005	throughput	[12446670.605op/s; 12473031.530op/s] or [-0.106%; +0.106%]	None	None	None
credit_card/is_card_number/ 378282246310005	execution_time	[74.938µs; 74.996µs] or [-0.039%; +0.039%]	None	None	None
credit_card/is_card_number/ 378282246310005	throughput	[13334227.021op/s; 13344510.269op/s] or [-0.039%; +0.039%]	None	None	None
credit_card/is_card_number/37828224631	execution_time	[3.910µs; 3.911µs] or [-0.009%; +0.009%]	None	None	None
credit_card/is_card_number/37828224631	throughput	[255674951.672op/s; 255723388.345op/s] or [-0.009%; +0.009%]	None	None	None
credit_card/is_card_number/378282246310005	execution_time	[72.051µs; 72.102µs] or [-0.035%; +0.035%]	None	None	None
credit_card/is_card_number/378282246310005	throughput	[13869406.659op/s; 13879122.729op/s] or [-0.035%; +0.035%]	None	None	None
credit_card/is_card_number/37828224631000521389798	execution_time	[52.196µs; 52.206µs] or [-0.009%; +0.009%]	None	None	None
credit_card/is_card_number/37828224631000521389798	throughput	[19155044.144op/s; 19158533.756op/s] or [-0.009%; +0.009%]	None	None	None
credit_card/is_card_number/x371413321323331	execution_time	[6.045µs; 6.047µs] or [-0.020%; +0.020%]	None	None	None
credit_card/is_card_number/x371413321323331	throughput	[165359677.751op/s; 165426438.285op/s] or [-0.020%; +0.020%]	None	None	None
credit_card/is_card_number_no_luhn/	execution_time	[3.911µs; 3.912µs] or [-0.013%; +0.013%]	None	None	None
credit_card/is_card_number_no_luhn/	throughput	[255615313.253op/s; 255681674.180op/s] or [-0.013%; +0.013%]	None	None	None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	execution_time	[64.295µs; 64.325µs] or [-0.024%; +0.024%]	None	None	None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	throughput	[15546075.251op/s; 15553434.808op/s] or [-0.024%; +0.024%]	None	None	None
credit_card/is_card_number_no_luhn/ 378282246310005	execution_time	[57.520µs; 57.549µs] or [-0.025%; +0.025%]	None	None	None
credit_card/is_card_number_no_luhn/ 378282246310005	throughput	[17376505.116op/s; 17385325.079op/s] or [-0.025%; +0.025%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631	execution_time	[3.911µs; 3.911µs] or [-0.009%; +0.009%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631	throughput	[255666516.049op/s; 255715095.326op/s] or [-0.009%; +0.009%]	None	None	None
credit_card/is_card_number_no_luhn/378282246310005	execution_time	[54.737µs; 54.775µs] or [-0.034%; +0.034%]	None	None	None
credit_card/is_card_number_no_luhn/378282246310005	throughput	[18256686.376op/s; 18269223.157op/s] or [-0.034%; +0.034%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631000521389798	execution_time	[52.206µs; 52.220µs] or [-0.013%; +0.013%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631000521389798	throughput	[19149708.702op/s; 19154856.689op/s] or [-0.013%; +0.013%]	None	None	None
credit_card/is_card_number_no_luhn/x371413321323331	execution_time	[6.045µs; 6.048µs] or [-0.021%; +0.021%]	None	None	None
credit_card/is_card_number_no_luhn/x371413321323331	throughput	[165346415.057op/s; 165415400.334op/s] or [-0.021%; +0.021%]	None	None	None

Group 15

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
profile_add_sample2_frames_x1000	execution_time	534.679µs	535.654µs ± 0.454µs	535.610µs ± 0.232µs	535.854µs	536.267µs	537.010µs	539.362µs	0.70%	3.089	21.496	0.08%	0.032µs	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
profile_add_sample2_frames_x1000	execution_time	[535.591µs; 535.717µs] or [-0.012%; +0.012%]	None	None	None

Group 16

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
single_flag_killswitch/rules-based	execution_time	189.046ns	191.499ns ± 2.114ns	191.243ns ± 1.464ns	192.618ns	195.709ns	197.803ns	201.527ns	5.38%	1.409	2.869	1.10%	0.150ns	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
single_flag_killswitch/rules-based	execution_time	[191.206ns; 191.792ns] or [-0.153%; +0.153%]	None	None	None

Group 17

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
benching string interning on wordpress profile	execution_time	162.009µs	162.529µs ± 0.336µs	162.445µs ± 0.179µs	162.691µs	163.112µs	163.620µs	164.407µs	1.21%	1.800	5.430	0.21%	0.024µs	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
benching string interning on wordpress profile	execution_time	[162.482µs; 162.575µs] or [-0.029%; +0.029%]	None	None	None

Group 18

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
normalization/normalize_trace/test_trace	execution_time	239.804ns	253.260ns ± 13.653ns	247.976ns ± 6.120ns	258.900ns	286.572ns	289.629ns	291.158ns	17.41%	1.322	0.767	5.38%	0.965ns	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
normalization/normalize_trace/test_trace	execution_time	[251.368ns; 255.152ns] or [-0.747%; +0.747%]	None	None	None

Group 19

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	7e5584e	1770729078	jwiriath/get-random-js-feature-for-wasm

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	10.677ms	10.710ms ± 0.023ms	10.707ms ± 0.009ms	10.717ms	10.733ms	10.768ms	10.967ms	2.43%	6.958	71.852	0.22%	0.002ms	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	[10.706ms; 10.713ms] or [-0.030%; +0.030%]	None	None	None

Baseline

Omitted due to size.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.91%. Comparing base (9e8a71a) to head (7e5584e).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1545      +/-   ##
==========================================
- Coverage   71.80%   70.91%   -0.89%     
==========================================
  Files         426      423       -3     
  Lines       70125    61653    -8472     
==========================================
- Hits        50353    43722    -6631     
+ Misses      19772    17931    -1841     

Components	Coverage Δ
libdd-crashtracker	62.37% <ø> (+0.05%)	⬆️
libdd-crashtracker-ffi	16.27% <ø> (-0.53%)	⬇️
libdd-alloc	98.77% <ø> (+0.04%)	⬆️
libdd-data-pipeline	85.70% <ø> (-1.16%)	⬇️
libdd-data-pipeline-ffi	74.78% <ø> (-3.90%)	⬇️
libdd-common	79.82% <ø> (-0.77%)	⬇️
libdd-common-ffi	73.75% <ø> (-0.80%)	⬇️
libdd-telemetry	62.52% <ø> (-2.58%)	⬇️
libdd-telemetry-ffi	16.75% <ø> (-4.43%)	⬇️
libdd-dogstatsd-client	82.64% <ø> (-1.11%)	⬇️
datadog-ipc	80.71% <ø> (-1.89%)	⬇️
libdd-profiling	81.52% <ø> (-0.32%)	⬇️
libdd-profiling-ffi	63.56% <ø> (-1.18%)	⬇️
datadog-sidecar	33.04% <ø> (-2.59%)	⬇️
datdog-sidecar-ffi	9.68% <ø> (-3.68%)	⬇️
spawn-worker	54.69% <ø> (-0.50%)	⬇️
libdd-tinybytes	93.16% <ø> (-0.28%)	⬇️
libdd-trace-normalization	81.71% <ø> (-0.63%)	⬇️
libdd-trace-obfuscation	94.18% <ø> (+0.01%)	⬆️
libdd-trace-protobuf	68.00% <ø> (+6.81%)	⬆️
libdd-trace-utils	88.78% <ø> (-0.59%)	⬇️
datadog-tracer-flare	91.63% <ø> (-2.02%)	⬇️
libdd-log	74.69% <ø> (-0.89%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[dd-octo-sts]

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	8.38 MB	8.38 MB	0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	91.69 MB	91.69 MB	+0% (+1.22 KB) 👌

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.76 MB	10.76 MB	+0% (+136 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	106.40 MB	106.40 MB	-0% (-4.78 KB) 👌

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	25.08 MB	25.08 MB	+0% (+1.00 KB) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	75.94 KB	75.94 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	172.51 MB	172.51 MB	0% (0 B) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	882.83 MB	882.64 MB	--.02% (-190.53 KB) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	9.57 MB	9.57 MB	+0% (+512 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	75.94 KB	75.94 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	23.04 MB	23.04 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	48.45 MB	48.45 MB	+0% (+562 B) 👌

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	21.22 MB	21.21 MB	--.05% (-12.00 KB) 💪
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	77.12 KB	77.12 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	176.63 MB	176.58 MB	--.03% (-56.00 KB) 💪
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	866.92 MB	866.68 MB	--.02% (-251.04 KB) 💪
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	7.24 MB	7.24 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	77.12 KB	77.12 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	24.62 MB	24.62 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	44.15 MB	44.15 MB	-0% (-1.33 KB) 👌

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	80.18 MB	80.18 MB	-0% (-1.42 KB) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	9.88 MB	9.88 MB	0% (0 B) 👌

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	100.31 MB	100.31 MB	-0% (-96 B) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	11.44 MB	11.44 MB	0% (0 B) 👌