chore(release): merge release branch to main by hoolioh · Pull Request #1550 · DataDog/libdatadog

hoolioh · 2026-02-10T15:45:49Z

This PR merges the release branch to main

# Release proposal for libdd-tinybytes and its dependencies This PR contains version bumps based on public API changes and commits since last release. ## libdd-tinybytes **Next version:** `1.1.0` **Semver bump:** `minor` **Tag:** `libdd-tinybytes-v1.1.0` ### Commits - feat(sidecar)!: introduce TraceData to unify text and binary data (#1247) - chore: add changelog for every published crate (#1396) --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Julio <julio.gonzalez@datadoghq.com>

github-actions · 2026-02-10T15:46:59Z

📚 Documentation Check Results

⚠️ 1235 documentation warning(s) found

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

📦 `libdd-tinybytes` - 7 warning(s)

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

Updated: 2026-02-10 15:49:14 UTC | Commit: f31617a | missing-docs job results

github-actions · 2026-02-10T15:50:07Z

🔒 Cargo Deny Results

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

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

📦 `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/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-trace-utils 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 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-02-10 15:52:58 UTC | Commit: f31617a | dependency-check job results

codecov-commenter · 2026-02-10T16:00:38Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.94%. Comparing base (d79d442) to head (59fbb06).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1550      +/-   ##
==========================================
+ Coverage   70.93%   70.94%   +0.01%     
==========================================
  Files         423      423              
  Lines       61680    61696      +16     
==========================================
+ Hits        43750    43773      +23     
+ Misses      17930    17923       -7

Components	Coverage Δ
libdd-crashtracker	`62.42% <ø> (+0.08%)`	⬆️
libdd-crashtracker-ffi	`16.74% <ø> (+0.93%)`	⬆️
libdd-alloc	`98.77% <ø> (ø)`
libdd-data-pipeline	`85.60% <ø> (-0.09%)`	⬇️
libdd-data-pipeline-ffi	`74.18% <ø> (-0.49%)`	⬇️
libdd-common	`79.82% <ø> (ø)`
libdd-common-ffi	`73.75% <ø> (ø)`
libdd-telemetry	`62.52% <ø> (ø)`
libdd-telemetry-ffi	`16.75% <ø> (ø)`
libdd-dogstatsd-client	`82.64% <ø> (ø)`
datadog-ipc	`80.71% <ø> (ø)`
libdd-profiling	`81.53% <ø> (ø)`
libdd-profiling-ffi	`63.56% <ø> (ø)`
datadog-sidecar	`33.62% <ø> (+0.01%)`	⬆️
datdog-sidecar-ffi	`12.23% <ø> (+0.07%)`	⬆️
spawn-worker	`54.69% <ø> (ø)`
libdd-tinybytes	`93.16% <ø> (ø)`
libdd-trace-normalization	`81.71% <ø> (ø)`
libdd-trace-obfuscation	`94.18% <ø> (ø)`
libdd-trace-protobuf	`68.00% <ø> (ø)`
libdd-trace-utils	`88.58% <ø> (ø)`
datadog-tracer-flare	`88.28% <ø> (-1.82%)`	⬇️
libdd-log	`74.69% <ø> (ø)`

🚀 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.

pr-commenter · 2026-03-13T10:53:21Z

Benchmarks

Comparison

Benchmark execution time: 2026-03-13 15:33:28

Comparing candidate commit 9e11973 in PR branch release with baseline commit 892b7bf in branch main.

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

Explanation

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

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

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

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

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

More details about the CI and significant changes

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

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

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

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

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

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

Candidate

Candidate benchmark details

Group 1

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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	246.108ns	254.945ns ± 12.233ns	249.567ns ± 2.031ns	253.635ns	282.887ns	295.938ns	301.238ns	20.70%	2.037	3.284	4.79%	0.865ns	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	[253.250ns; 256.641ns] or [-0.665%; +0.665%]	None	None	None

Group 2

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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	144.640µs	146.487µs ± 1.765µs	146.242µs ± 0.479µs	146.716µs	147.937µs	152.502µs	164.660µs	12.59%	6.549	58.439	1.20%	0.125µ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	[146.242µs; 146.731µs] or [-0.167%; +0.167%]	None	None	None

Group 3

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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.699µs	205.656µs ± 0.681µs	205.471µs ± 0.380µs	205.983µs	207.040µs	207.607µs	208.044µs	1.25%	1.179	0.967	0.33%	0.048µs	1	200
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...	throughput	4806668.642op/s	4862537.892op/s ± 16041.362op/s	4866870.059op/s ± 8988.957op/s	4874116.875op/s	4880923.120op/s	4882641.317op/s	4885233.326op/s	0.38%	-1.164	0.920	0.33%	1134.296op/s	1	200
normalization/normalize_name/normalize_name/bad-name	execution_time	18.563µs	18.688µs ± 0.093µs	18.650µs ± 0.034µs	18.720µs	18.871µs	19.006µs	19.167µs	2.77%	1.742	3.869	0.50%	0.007µs	1	200
normalization/normalize_name/normalize_name/bad-name	throughput	52173766.942op/s	53510320.900op/s ± 264489.676op/s	53618413.692op/s ± 96825.902op/s	53680479.234op/s	53772415.182op/s	53849590.397op/s	53870455.251op/s	0.47%	-1.701	3.622	0.49%	18702.244op/s	1	200
normalization/normalize_name/normalize_name/good	execution_time	10.629µs	10.731µs ± 0.050µs	10.721µs ± 0.024µs	10.750µs	10.832µs	10.872µs	10.994µs	2.54%	1.485	3.957	0.46%	0.004µs	1	200
normalization/normalize_name/normalize_name/good	throughput	90957062.712op/s	93190742.432op/s ± 431003.336op/s	93271892.556op/s ± 209259.938op/s	93458694.047op/s	93669801.940op/s	93979026.391op/s	94080403.555op/s	0.87%	-1.434	3.696	0.46%	30476.538op/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.562µs; 205.751µs] or [-0.046%; +0.046%]	None	None	None
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...	throughput	[4860314.714op/s; 4864761.070op/s] or [-0.046%; +0.046%]	None	None	None
normalization/normalize_name/normalize_name/bad-name	execution_time	[18.676µs; 18.701µs] or [-0.069%; +0.069%]	None	None	None
normalization/normalize_name/normalize_name/bad-name	throughput	[53473665.174op/s; 53546976.625op/s] or [-0.069%; +0.069%]	None	None	None
normalization/normalize_name/normalize_name/good	execution_time	[10.724µs; 10.738µs] or [-0.065%; +0.065%]	None	None	None
normalization/normalize_name/normalize_name/good	throughput	[93131009.515op/s; 93250475.349op/s] or [-0.064%; +0.064%]	None	None	None

Group 4

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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.656ms	14.699ms ± 0.031ms	14.694ms ± 0.013ms	14.707ms	14.740ms	14.825ms	14.853ms	1.08%	2.453	8.042	0.21%	0.002ms	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.695ms; 14.703ms] or [-0.029%; +0.029%]	None	None	None

Group 5

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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	159.526µs	160.665µs ± 0.357µs	160.592µs ± 0.152µs	160.790µs	161.212µs	161.613µs	163.607µs	1.88%	3.130	22.483	0.22%	0.025µ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	[160.615µs; 160.714µs] or [-0.031%; +0.031%]	None	None	None

Group 6

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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	49.019ms	49.512ms ± 1.262ms	49.384ms ± 0.150ms	49.482ms	49.629ms	57.437ms	61.065ms	23.65%	7.897	63.294	2.54%	0.089ms	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	[49.337ms; 49.687ms] or [-0.353%; +0.353%]	None	None	None

Group 7

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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	89.104µs	89.288µs ± 0.180µs	89.266µs ± 0.047µs	89.313µs	89.410µs	89.841µs	91.252µs	2.22%	7.472	73.438	0.20%	0.013µ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	[89.264µs; 89.313µs] or [-0.028%; +0.028%]	None	None	None

Group 8

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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.311µs	2.380µs ± 0.022µs	2.376µs ± 0.008µs	2.392µs	2.420µs	2.424µs	2.439µs	2.64%	-0.272	1.278	0.93%	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.377µs; 2.383µs] or [-0.130%; +0.130%]	None	None	None

Group 9

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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	493.302µs	494.420µs ± 0.430µs	494.415µs ± 0.330µs	494.754µs	495.038µs	495.224µs	495.570µs	0.23%	-0.184	-0.534	0.09%	0.030µs	1	200
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...	throughput	2017879.986op/s	2022574.344op/s ± 1758.126op/s	2022591.107op/s ± 1347.159op/s	2023692.265op/s	2025475.133op/s	2026775.826op/s	2027153.952op/s	0.23%	0.188	-0.533	0.09%	124.318op/s	1	200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	execution_time	369.814µs	370.476µs ± 0.261µs	370.474µs ± 0.178µs	370.627µs	370.898µs	371.204µs	371.407µs	0.25%	0.487	0.451	0.07%	0.018µs	1	200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	throughput	2692462.486op/s	2699231.301op/s ± 1900.466op/s	2699242.217op/s ± 1299.087op/s	2700594.747op/s	2702024.688op/s	2702559.845op/s	2704059.181op/s	0.18%	-0.482	0.443	0.07%	134.383op/s	1	200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	execution_time	167.338µs	167.653µs ± 0.165µs	167.626µs ± 0.085µs	167.739µs	167.968µs	168.143µs	168.482µs	0.51%	1.285	3.169	0.10%	0.012µs	1	200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	throughput	5935348.048op/s	5964696.765op/s ± 5868.334op/s	5965651.306op/s ± 3025.046op/s	5968195.970op/s	5972065.663op/s	5974488.221op/s	5975928.958op/s	0.17%	-1.275	3.121	0.10%	414.954op/s	1	200
normalization/normalize_service/normalize_service/[empty string]	execution_time	37.210µs	37.317µs ± 0.049µs	37.318µs ± 0.039µs	37.354µs	37.397µs	37.409µs	37.454µs	0.37%	-0.016	-0.635	0.13%	0.003µs	1	200
normalization/normalize_service/normalize_service/[empty string]	throughput	26699334.087op/s	26797551.792op/s ± 35519.478op/s	26796969.299op/s ± 27677.822op/s	26825007.853op/s	26853083.744op/s	26868274.866op/s	26874619.309op/s	0.29%	0.021	-0.637	0.13%	2511.606op/s	1	200
normalization/normalize_service/normalize_service/test_ASCII	execution_time	45.566µs	45.725µs ± 0.064µs	45.725µs ± 0.043µs	45.766µs	45.838µs	45.864µs	45.887µs	0.35%	0.020	-0.263	0.14%	0.005µs	1	200
normalization/normalize_service/normalize_service/test_ASCII	throughput	21792782.043op/s	21869755.073op/s ± 30634.051op/s	21869966.823op/s ± 20785.421op/s	21890953.512op/s	21922187.363op/s	21935113.498op/s	21946193.126op/s	0.35%	-0.013	-0.263	0.14%	2166.155op/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	[494.360µs; 494.479µs] or [-0.012%; +0.012%]	None	None	None
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...	throughput	[2022330.685op/s; 2022818.004op/s] or [-0.012%; +0.012%]	None	None	None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	execution_time	[370.440µs; 370.512µs] or [-0.010%; +0.010%]	None	None	None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	throughput	[2698967.914op/s; 2699494.687op/s] or [-0.010%; +0.010%]	None	None	None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	execution_time	[167.630µs; 167.676µs] or [-0.014%; +0.014%]	None	None	None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	throughput	[5963883.470op/s; 5965510.059op/s] or [-0.014%; +0.014%]	None	None	None
normalization/normalize_service/normalize_service/[empty string]	execution_time	[37.310µs; 37.324µs] or [-0.018%; +0.018%]	None	None	None
normalization/normalize_service/normalize_service/[empty string]	throughput	[26792629.134op/s; 26802474.450op/s] or [-0.018%; +0.018%]	None	None	None
normalization/normalize_service/normalize_service/test_ASCII	execution_time	[45.716µs; 45.734µs] or [-0.019%; +0.019%]	None	None	None
normalization/normalize_service/normalize_service/test_ASCII	throughput	[21865509.488op/s; 21874000.658op/s] or [-0.019%; +0.019%]	None	None	None

Group 10

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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.896µs	3.915µs ± 0.003µs	3.915µs ± 0.002µs	3.917µs	3.919µs	3.923µs	3.925µs	0.25%	-0.904	7.826	0.08%	0.000µs	1	200
credit_card/is_card_number/	throughput	254787236.696op/s	255424124.933op/s ± 199497.038op/s	255430127.984op/s ± 122787.813op/s	255541972.737op/s	255697154.616op/s	255790565.688op/s	256701837.700op/s	0.50%	0.925	7.949	0.08%	14106.571op/s	1	200
credit_card/is_card_number/ 3782-8224-6310-005	execution_time	79.478µs	80.047µs ± 0.100µs	80.032µs ± 0.045µs	80.094µs	80.220µs	80.342µs	80.482µs	0.56%	0.060	6.414	0.13%	0.007µs	1	200
credit_card/is_card_number/ 3782-8224-6310-005	throughput	12425071.847op/s	12492625.902op/s ± 15659.576op/s	12494948.918op/s ± 6973.589op/s	12500835.369op/s	12512491.846op/s	12521285.299op/s	12582105.790op/s	0.70%	-0.028	6.508	0.13%	1107.299op/s	1	200
credit_card/is_card_number/ 378282246310005	execution_time	67.818µs	67.951µs ± 0.136µs	67.931µs ± 0.038µs	67.973µs	68.057µs	68.634µs	69.153µs	1.80%	6.280	47.533	0.20%	0.010µs	1	200
credit_card/is_card_number/ 378282246310005	throughput	14460753.612op/s	14716507.446op/s ± 29085.857op/s	14720786.711op/s ± 8135.668op/s	14728707.532op/s	14737015.471op/s	14743927.767op/s	14745337.559op/s	0.17%	-6.220	46.822	0.20%	2056.681op/s	1	200
credit_card/is_card_number/37828224631	execution_time	3.894µs	3.915µs ± 0.003µs	3.914µs ± 0.002µs	3.916µs	3.919µs	3.921µs	3.922µs	0.19%	-1.487	11.139	0.07%	0.000µs	1	200
credit_card/is_card_number/37828224631	throughput	254983963.455op/s	255458906.574op/s ± 189031.446op/s	255462268.223op/s ± 102986.842op/s	255560689.275op/s	255728138.912op/s	255796247.103op/s	256794604.318op/s	0.52%	1.511	11.328	0.07%	13366.542op/s	1	200
credit_card/is_card_number/378282246310005	execution_time	64.582µs	64.702µs ± 0.066µs	64.696µs ± 0.034µs	64.733µs	64.778µs	64.846µs	65.323µs	0.97%	4.409	38.549	0.10%	0.005µs	1	200
credit_card/is_card_number/378282246310005	throughput	15308549.746op/s	15455431.642op/s ± 15610.103op/s	15457017.898op/s ± 8083.972op/s	15464118.992op/s	15474652.596op/s	15478489.312op/s	15484091.644op/s	0.18%	-4.345	37.760	0.10%	1103.801op/s	1	200
credit_card/is_card_number/37828224631000521389798	execution_time	45.462µs	45.701µs ± 0.104µs	45.705µs ± 0.072µs	45.769µs	45.865µs	45.905µs	45.958µs	0.55%	-0.043	-0.484	0.23%	0.007µs	1	200
credit_card/is_card_number/37828224631000521389798	throughput	21759008.155op/s	21881449.591op/s ± 49966.856op/s	21879231.145op/s ± 34632.997op/s	21918022.693op/s	21962482.195op/s	21989543.135op/s	21996549.455op/s	0.54%	0.053	-0.484	0.23%	3533.190op/s	1	200
credit_card/is_card_number/x371413321323331	execution_time	6.577µs	6.632µs ± 0.012µs	6.635µs ± 0.006µs	6.640µs	6.645µs	6.647µs	6.648µs	0.19%	-1.611	3.303	0.18%	0.001µs	1	200
credit_card/is_card_number/x371413321323331	throughput	150427458.052op/s	150793111.165op/s ± 278825.199op/s	150709981.248op/s ± 140829.648op/s	150899338.844op/s	151376317.852op/s	151612269.946op/s	152052339.033op/s	0.89%	1.626	3.379	0.18%	19715.919op/s	1	200
credit_card/is_card_number_no_luhn/	execution_time	3.897µs	3.915µs ± 0.003µs	3.915µs ± 0.002µs	3.917µs	3.920µs	3.921µs	3.924µs	0.23%	-0.878	7.603	0.07%	0.000µs	1	200
credit_card/is_card_number_no_luhn/	throughput	254852500.373op/s	255415271.519op/s ± 185408.182op/s	255432337.740op/s ± 100002.465op/s	255515409.923op/s	255661131.006op/s	255758468.483op/s	256604862.471op/s	0.46%	0.897	7.722	0.07%	13110.338op/s	1	200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	execution_time	65.118µs	65.690µs ± 0.063µs	65.691µs ± 0.030µs	65.723µs	65.776µs	65.800µs	65.837µs	0.22%	-3.657	33.084	0.10%	0.004µs	1	200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	throughput	15188946.021op/s	15222987.529op/s ± 14574.708op/s	15222862.710op/s ± 6933.111op/s	15229485.957op/s	15239860.311op/s	15246141.567op/s	15356684.594op/s	0.88%	3.720	33.793	0.10%	1030.588op/s	1	200
credit_card/is_card_number_no_luhn/ 378282246310005	execution_time	53.368µs	53.458µs ± 0.037µs	53.457µs ± 0.025µs	53.482µs	53.516µs	53.548µs	53.580µs	0.23%	0.303	0.158	0.07%	0.003µs	1	200
credit_card/is_card_number_no_luhn/ 378282246310005	throughput	18663786.090op/s	18706324.025op/s ± 12817.821op/s	18706753.382op/s ± 8866.754op/s	18715661.614op/s	18725925.669op/s	18731120.314op/s	18737680.349op/s	0.17%	-0.299	0.151	0.07%	906.357op/s	1	200
credit_card/is_card_number_no_luhn/37828224631	execution_time	3.894µs	3.915µs ± 0.003µs	3.915µs ± 0.002µs	3.916µs	3.919µs	3.920µs	3.921µs	0.17%	-2.379	14.859	0.08%	0.000µs	1	200
credit_card/is_card_number_no_luhn/37828224631	throughput	255016531.641op/s	255453706.612op/s ± 205909.576op/s	255456417.553op/s ± 108025.389op/s	255560875.572op/s	255696672.091op/s	255810801.759op/s	256820732.291op/s	0.53%	2.406	15.061	0.08%	14560.006op/s	1	200
credit_card/is_card_number_no_luhn/378282246310005	execution_time	50.139µs	50.211µs ± 0.034µs	50.208µs ± 0.023µs	50.232µs	50.280µs	50.299µs	50.308µs	0.20%	0.495	0.031	0.07%	0.002µs	1	200
credit_card/is_card_number_no_luhn/378282246310005	throughput	19877577.973op/s	19915854.737op/s ± 13678.178op/s	19917245.835op/s ± 9182.512op/s	19925209.233op/s	19936185.970op/s	19941762.936op/s	19944703.310op/s	0.14%	-0.491	0.027	0.07%	967.193op/s	1	200
credit_card/is_card_number_no_luhn/37828224631000521389798	execution_time	45.457µs	45.706µs ± 0.104µs	45.708µs ± 0.075µs	45.781µs	45.866µs	45.926µs	45.949µs	0.53%	-0.073	-0.491	0.23%	0.007µs	1	200
credit_card/is_card_number_no_luhn/37828224631000521389798	throughput	21763339.287op/s	21879037.957op/s ± 49761.659op/s	21878110.951op/s ± 36116.863op/s	21914527.691op/s	21964440.704op/s	21987751.759op/s	21998820.903op/s	0.55%	0.083	-0.489	0.23%	3518.681op/s	1	200
credit_card/is_card_number_no_luhn/x371413321323331	execution_time	6.581µs	6.629µs ± 0.013µs	6.634µs ± 0.004µs	6.637µs	6.641µs	6.644µs	6.645µs	0.17%	-1.575	2.127	0.19%	0.001µs	1	200
credit_card/is_card_number_no_luhn/x371413321323331	throughput	150488669.598op/s	150847376.213op/s ± 290681.986op/s	150738498.858op/s ± 94719.024op/s	150939424.251op/s	151450520.389op/s	151742918.693op/s	151958539.270op/s	0.81%	1.584	2.168	0.19%	20554.320op/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.915µs; 3.915µs] or [-0.011%; +0.011%]	None	None	None
credit_card/is_card_number/	throughput	[255396476.562op/s; 255451773.304op/s] or [-0.011%; +0.011%]	None	None	None
credit_card/is_card_number/ 3782-8224-6310-005	execution_time	[80.033µs; 80.061µs] or [-0.017%; +0.017%]	None	None	None
credit_card/is_card_number/ 3782-8224-6310-005	throughput	[12490455.635op/s; 12494796.168op/s] or [-0.017%; +0.017%]	None	None	None
credit_card/is_card_number/ 378282246310005	execution_time	[67.932µs; 67.970µs] or [-0.028%; +0.028%]	None	None	None
credit_card/is_card_number/ 378282246310005	throughput	[14712476.426op/s; 14720538.466op/s] or [-0.027%; +0.027%]	None	None	None
credit_card/is_card_number/37828224631	execution_time	[3.914µs; 3.915µs] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number/37828224631	throughput	[255432708.633op/s; 255485104.514op/s] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number/378282246310005	execution_time	[64.693µs; 64.711µs] or [-0.014%; +0.014%]	None	None	None
credit_card/is_card_number/378282246310005	throughput	[15453268.232op/s; 15457595.052op/s] or [-0.014%; +0.014%]	None	None	None
credit_card/is_card_number/37828224631000521389798	execution_time	[45.687µs; 45.716µs] or [-0.032%; +0.032%]	None	None	None
credit_card/is_card_number/37828224631000521389798	throughput	[21874524.665op/s; 21888374.517op/s] or [-0.032%; +0.032%]	None	None	None
credit_card/is_card_number/x371413321323331	execution_time	[6.630µs; 6.633µs] or [-0.026%; +0.026%]	None	None	None
credit_card/is_card_number/x371413321323331	throughput	[150754468.674op/s; 150831753.656op/s] or [-0.026%; +0.026%]	None	None	None
credit_card/is_card_number_no_luhn/	execution_time	[3.915µs; 3.916µs] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number_no_luhn/	throughput	[255389575.728op/s; 255440967.310op/s] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	execution_time	[65.682µs; 65.699µs] or [-0.013%; +0.013%]	None	None	None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	throughput	[15220967.615op/s; 15225007.444op/s] or [-0.013%; +0.013%]	None	None	None
credit_card/is_card_number_no_luhn/ 378282246310005	execution_time	[53.453µs; 53.463µs] or [-0.009%; +0.009%]	None	None	None
credit_card/is_card_number_no_luhn/ 378282246310005	throughput	[18704547.598op/s; 18708100.452op/s] or [-0.009%; +0.009%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631	execution_time	[3.914µs; 3.915µs] or [-0.011%; +0.011%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631	throughput	[255425169.525op/s; 255482243.699op/s] or [-0.011%; +0.011%]	None	None	None
credit_card/is_card_number_no_luhn/378282246310005	execution_time	[50.206µs; 50.216µs] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number_no_luhn/378282246310005	throughput	[19913959.073op/s; 19917750.400op/s] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631000521389798	execution_time	[45.692µs; 45.720µs] or [-0.032%; +0.032%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631000521389798	throughput	[21872141.470op/s; 21885934.445op/s] or [-0.032%; +0.032%]	None	None	None
credit_card/is_card_number_no_luhn/x371413321323331	execution_time	[6.627µs; 6.631µs] or [-0.027%; +0.027%]	None	None	None
credit_card/is_card_number_no_luhn/x371413321323331	throughput	[150807090.485op/s; 150887661.940op/s] or [-0.027%; +0.027%]	None	None	None

Group 11

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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	17.931µs	26.089µs ± 9.061µs	19.371µs ± 0.914µs	33.375µs	42.459µs	49.713µs	66.669µs	244.17%	1.022	0.868	34.64%	0.641µ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.833µs; 27.344µs] or [-4.813%; +4.813%]	None	None	None

Group 12

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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	734.525µs	737.546µs ± 0.940µs	737.504µs ± 0.543µs	738.050µs	739.287µs	739.900µs	740.536µs	0.41%	0.187	0.502	0.13%	0.066µ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	[737.416µs; 737.676µs] or [-0.018%; +0.018%]	None	None	None

Group 13

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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	12.996ms	13.029ms ± 0.015ms	13.027ms ± 0.009ms	13.037ms	13.052ms	13.068ms	13.101ms	0.56%	1.077	3.641	0.11%	0.001ms	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
concentrator/add_spans_to_concentrator	execution_time	[13.027ms; 13.031ms] or [-0.016%; +0.016%]	None	None	None

Group 14

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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	32.879µs	33.645µs ± 1.016µs	33.017µs ± 0.081µs	35.083µs	35.446µs	35.518µs	36.519µs	10.61%	1.028	-0.748	3.01%	0.072µ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	[33.504µs; 33.786µs] or [-0.419%; +0.419%]	None	None	None

Group 15

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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	190.705ns	193.427ns ± 2.250ns	193.087ns ± 1.280ns	194.294ns	197.512ns	201.883ns	203.854ns	5.58%	1.541	3.939	1.16%	0.159ns	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	[193.115ns; 193.739ns] or [-0.161%; +0.161%]	None	None	None

Group 16

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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	4.962µs	5.040µs ± 0.039µs	5.024µs ± 0.019µs	5.074µs	5.110µs	5.113µs	5.116µs	1.84%	0.387	-0.879	0.76%	0.003µ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.035µs; 5.046µs] or [-0.106%; +0.106%]	None	None	None

Group 17

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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/2598	execution_time	3.387ms	3.417ms ± 0.023ms	3.411ms ± 0.007ms	3.420ms	3.457ms	3.504ms	3.549ms	4.04%	3.063	11.400	0.67%	0.002ms	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
receiver_entry_point/report/2598	execution_time	[3.414ms; 3.420ms] or [-0.092%; +0.092%]	None	None	None

Group 18

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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	4.132ms	4.138ms ± 0.007ms	4.137ms ± 0.002ms	4.139ms	4.142ms	4.146ms	4.234ms	2.34%	11.550	149.511	0.18%	0.001ms	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	[4.137ms; 4.139ms] or [-0.024%; +0.024%]	None	None	None

Group 19

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`9e11973`	1773414980	release

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.157µs	3.176µs ± 1.436µs	3.002µs ± 0.024µs	3.024µs	3.363µs	13.848µs	15.241µs	407.69%	7.535	57.312	45.11%	0.102µs	1	200

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

Baseline

Omitted due to size.

hoolioh requested review from a team as code owners February 10, 2026 15:45

github-actions Bot added mini-agent data-pipeline labels Feb 10, 2026

hoolioh added skip-metadata-check skip-changelog-check labels Feb 10, 2026

iunanua approved these changes Feb 10, 2026

View reviewed changes

hoolioh merged commit d52ee90 into main Feb 10, 2026
103 of 106 checks passed

dd-octo-sts Bot mentioned this pull request Feb 16, 2026

chore(release): proposal for libdd-data-pipeline #1572

Closed

dd-octo-sts Bot mentioned this pull request Feb 25, 2026

chore(release): merge release branch to main #1629

Merged

Conversation

hoolioh commented Feb 10, 2026

Uh oh!

github-actions Bot commented Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📚 Documentation Check Results

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

📦 libdd-tinybytes - 7 warning(s)

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

Uh oh!

github-actions Bot commented Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔒 Cargo Deny Results

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

📦 libdd-tinybytes - ✅ No issues

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

Uh oh!

codecov-commenter commented Feb 10, 2026

Codecov Report

Uh oh!

Uh oh!

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

Uh oh!

Benchmarks

Comparison

Explanation

More details about the CI and significant changes

Candidate

Group 1

Group 2

Group 3

Group 4

Group 5

Group 6

Group 7

Group 8

Group 9

Group 10

Group 11

Group 12

Group 13

Group 14

Group 15

Group 16

Group 17

Group 18

Group 19

Baseline

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

github-actions Bot commented Feb 10, 2026 •

edited

Loading

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

📦 `libdd-tinybytes` - 7 warning(s)

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

github-actions Bot commented Feb 10, 2026 •

edited

Loading

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

📦 `libdd-tinybytes` - ✅ No issues

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

pr-commenter Bot commented Mar 13, 2026 •

edited

Loading