chore(release): proposal for libdd-telemetry by dd-octo-sts[bot] · Pull Request #1818 · DataDog/libdatadog

dd-octo-sts · 2026-03-30T09:32:39Z

Release proposal for libdd-telemetry and its dependencies

This PR contains version bumps based on public API changes and commits since last release.

Cut from non-default ref

This proposal was generated from 5ff99ff6c465a95a740a494f42cce258c0e80be8 instead of the default latest origin/main.

Non-default workflow options

bypass_standard_checks was enabled: the ongoing-proposal branch guard was skipped; branches use proposal prefix release-proposal-testing and release prefix release-testing. Crates whose resolved git tag is not the latest SemVer tag for that crate are still included (normally skipped).

libdd-common

Next version: 3.0.1
Semver bump: patch
Tag: libdd-common-v3.0.1

Commits

chore(build): update reqwest and quinn-proto dependency for dependabot alert (chore(build): update reqwest and quinn-proto dependency for dependabot alert #1774)
chore(build): ekump/APMSP-2718 update aws-lc dependencies (chore(build): ekump/APMSP-2718 update aws-lc dependencies #1751)

libdd-telemetry

Next version: 4.0.0
Semver bump: major
Tag: libdd-telemetry-v4.0.0

libdd dependency major bumps

libdd-common: ^2.0.0 → ^3.0.1

Commits

refactor(sidecar)!: Refactor tarpc away (refactor(sidecar)!: Refactor tarpc away #1742)

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

github-actions · 2026-03-30T09:35:16Z

📚 Documentation Check Results

⚠️ 4307 documentation warning(s) found

📦 `libdd-common` - 166 warning(s)

📦 `libdd-crashtracker` - 1049 warning(s)

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

📦 `libdd-dogstatsd-client` - 166 warning(s)

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

📦 `libdd-telemetry` - 476 warning(s)

📦 `libdd-trace-obfuscation` - 522 warning(s)

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

Updated: 2026-03-30 09:55:47 UTC | Commit: df910c7 | missing-docs job results

github-actions · 2026-03-30T09:36:56Z

🔒 Cargo Deny Results

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

📦 `libdd-common` - 3 error(s)

Show output

error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
  ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:6:1
  │
6 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
  │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
  │
  ├ ID: RUSTSEC-2026-0044
  ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
  ├ A logic error in CN (Common Name) validation allows certificates with
    wildcard or raw UTF-8 Unicode CN values to bypass name constraints
    enforcement. The `cn2dnsid` function does not recognize these CN patterns
    as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
    validation. However, `X509_check_host` accepts these CN values when no
    dNSName SAN is present, allowing certificates to bypass name constraints
    while still being used for hostname verification.
    
    Customers of AWS services do not need to take action. Applications using
    `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
    
    ## Workarounds
    
    Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
    fallback are not affected. Applications that only encounter certificates
    with dNSName SANs (standard for public WebPKI) are also not affected.
    
    Otherwise, there is no workaround and applications using `aws-lc-sys` should
    upgrade to the most recent releases of `aws-lc-sys`.
  ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
  ├ aws-lc-sys v0.38.0
    └── aws-lc-rs v1.16.1
        ├── rustls v0.23.37
        │   ├── hyper-rustls v0.27.7
        │   │   ├── libdd-common v3.0.1
        │   │   └── reqwest v0.13.2
        │   │       └── libdd-common v3.0.1 (*)
        │   ├── libdd-common v3.0.1 (*)
        │   ├── reqwest v0.13.2 (*)
        │   ├── rustls-platform-verifier v0.6.2
        │   │   └── reqwest v0.13.2 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       ├── libdd-common v3.0.1 (*)
        │       └── reqwest v0.13.2 (*)
        └── rustls-webpki v0.103.9
            ├── rustls v0.23.37 (*)
            └── rustls-platform-verifier v0.6.2 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
  ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:6:1
  │
6 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
  │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
  │
  ├ ID: RUSTSEC-2026-0048
  ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
  ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
    certificate to bypass revocation checks during certificate validation, when
    the application enables CRL checking and uses partitioned CRLs with Issuing
    Distribution Point (IDP) extensions.
    
    Customers of AWS services do not need to take action. `aws-lc-sys` contains
    code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
    recent release of `aws-lc-sys`.
    
    ## Workarounds
    
    Applications can workaround this issue if they do not enable CRL checking
    (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
    CRLs without IDP extensions are also not affected.
    
    Otherwise, there is no workaround and applications using `aws-lc-sys` should
    upgrade to the most recent releases of `aws-lc-sys`.
  ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
  ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
  ├ aws-lc-sys v0.38.0
    └── aws-lc-rs v1.16.1
        ├── rustls v0.23.37
        │   ├── hyper-rustls v0.27.7
        │   │   ├── libdd-common v3.0.1
        │   │   └── reqwest v0.13.2
        │   │       └── libdd-common v3.0.1 (*)
        │   ├── libdd-common v3.0.1 (*)
        │   ├── reqwest v0.13.2 (*)
        │   ├── rustls-platform-verifier v0.6.2
        │   │   └── reqwest v0.13.2 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       ├── libdd-common v3.0.1 (*)
        │       └── reqwest v0.13.2 (*)
        └── rustls-webpki v0.103.9
            ├── rustls v0.23.37 (*)
            └── rustls-platform-verifier v0.6.2 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:130:1
    │
130 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      ├── rustls v0.23.37
      │   ├── hyper-rustls v0.27.7
      │   │   ├── libdd-common v3.0.1
      │   │   └── reqwest v0.13.2
      │   │       └── libdd-common v3.0.1 (*)
      │   ├── libdd-common v3.0.1 (*)
      │   ├── reqwest v0.13.2 (*)
      │   ├── rustls-platform-verifier v0.6.2
      │   │   └── reqwest v0.13.2 (*)
      │   └── tokio-rustls v0.26.0
      │       ├── hyper-rustls v0.27.7 (*)
      │       ├── libdd-common v3.0.1 (*)
      │       └── reqwest v0.13.2 (*)
      └── rustls-platform-verifier v0.6.2 (*)

advisories FAILED, bans ok, sources ok

📦 `libdd-crashtracker` - 4 error(s)

Show output

error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:11:1
   │
11 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0044
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
   ├ A logic error in CN (Common Name) validation allows certificates with
     wildcard or raw UTF-8 Unicode CN values to bypass name constraints
     enforcement. The `cn2dnsid` function does not recognize these CN patterns
     as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
     validation. However, `X509_check_host` accepts these CN values when no
     dNSName SAN is present, allowing certificates to bypass name constraints
     while still being used for hostname verification.
     
     Customers of AWS services do not need to take action. Applications using
     `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
     fallback are not affected. Applications that only encounter certificates
     with dNSName SANs (standard for public WebPKI) are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       ├── (build) libdd-crashtracker v1.0.0
         │   │       └── libdd-telemetry v4.0.0
         │   │           └── libdd-crashtracker v1.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:11:1
   │
11 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0048
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
   ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
     certificate to bypass revocation checks during certificate validation, when
     the application enables CRL checking and uses partitioned CRLs with Issuing
     Distribution Point (IDP) extensions.
     
     Customers of AWS services do not need to take action. `aws-lc-sys` contains
     code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
     recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications can workaround this issue if they do not enable CRL checking
     (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
     CRLs without IDP extensions are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       ├── (build) libdd-crashtracker v1.0.0
         │   │       └── libdd-telemetry v4.0.0
         │   │           └── libdd-crashtracker v1.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

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

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:162:1
    │
162 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       ├── (build) libdd-crashtracker v1.0.0
          │       └── libdd-telemetry v4.0.0
          │           └── libdd-crashtracker v1.0.0 (*)
          ├── libdd-common v3.0.1 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

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

Show output

error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:32:1
   │
32 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0044
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
   ├ A logic error in CN (Common Name) validation allows certificates with
     wildcard or raw UTF-8 Unicode CN values to bypass name constraints
     enforcement. The `cn2dnsid` function does not recognize these CN patterns
     as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
     validation. However, `X509_check_host` accepts these CN values when no
     dNSName SAN is present, allowing certificates to bypass name constraints
     while still being used for hostname verification.
     
     Customers of AWS services do not need to take action. Applications using
     `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
     fallback are not affected. Applications that only encounter certificates
     with dNSName SANs (standard for public WebPKI) are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       ├── libdd-data-pipeline v2.0.1
         │   │       ├── libdd-dogstatsd-client v1.0.1
         │   │       │   └── libdd-data-pipeline v2.0.1 (*)
         │   │       ├── libdd-telemetry v4.0.0
         │   │       │   └── libdd-data-pipeline v2.0.1 (*)
         │   │       └── libdd-trace-utils v2.0.2
         │   │           ├── libdd-data-pipeline v2.0.1 (*)
         │   │           ├── libdd-trace-stats v1.0.3
         │   │           │   └── libdd-data-pipeline v2.0.1 (*)
         │   │           └── (dev) libdd-trace-utils v2.0.2 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:32:1
   │
32 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0048
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
   ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
     certificate to bypass revocation checks during certificate validation, when
     the application enables CRL checking and uses partitioned CRLs with Issuing
     Distribution Point (IDP) extensions.
     
     Customers of AWS services do not need to take action. `aws-lc-sys` contains
     code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
     recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications can workaround this issue if they do not enable CRL checking
     (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
     CRLs without IDP extensions are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       ├── libdd-data-pipeline v2.0.1
         │   │       ├── libdd-dogstatsd-client v1.0.1
         │   │       │   └── libdd-data-pipeline v2.0.1 (*)
         │   │       ├── libdd-telemetry v4.0.0
         │   │       │   └── libdd-data-pipeline v2.0.1 (*)
         │   │       └── libdd-trace-utils v2.0.2
         │   │           ├── libdd-data-pipeline v2.0.1 (*)
         │   │           ├── libdd-trace-stats v1.0.3
         │   │           │   └── libdd-data-pipeline v2.0.1 (*)
         │   │           └── (dev) libdd-trace-utils v2.0.2 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:241:1
    │
241 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       ├── libdd-data-pipeline v2.0.1
          │       ├── libdd-dogstatsd-client v1.0.1
          │       │   └── libdd-data-pipeline v2.0.1 (*)
          │       ├── libdd-telemetry v4.0.0
          │       │   └── libdd-data-pipeline v2.0.1 (*)
          │       └── libdd-trace-utils v2.0.2
          │           ├── libdd-data-pipeline v2.0.1 (*)
          │           ├── libdd-trace-stats v1.0.3
          │           │   └── libdd-data-pipeline v2.0.1 (*)
          │           └── (dev) libdd-trace-utils v2.0.2 (*)
          ├── libdd-common v3.0.1 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.1 (*)

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

advisories FAILED, bans ok, sources ok

📦 `libdd-dogstatsd-client` - 3 error(s)

Show output

error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
  ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:5:1
  │
5 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
  │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
  │
  ├ ID: RUSTSEC-2026-0044
  ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
  ├ A logic error in CN (Common Name) validation allows certificates with
    wildcard or raw UTF-8 Unicode CN values to bypass name constraints
    enforcement. The `cn2dnsid` function does not recognize these CN patterns
    as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
    validation. However, `X509_check_host` accepts these CN values when no
    dNSName SAN is present, allowing certificates to bypass name constraints
    while still being used for hostname verification.
    
    Customers of AWS services do not need to take action. Applications using
    `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
    
    ## Workarounds
    
    Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
    fallback are not affected. Applications that only encounter certificates
    with dNSName SANs (standard for public WebPKI) are also not affected.
    
    Otherwise, there is no workaround and applications using `aws-lc-sys` should
    upgrade to the most recent releases of `aws-lc-sys`.
  ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
  ├ aws-lc-sys v0.38.0
    └── aws-lc-rs v1.16.1
        ├── rustls v0.23.37
        │   ├── hyper-rustls v0.27.7
        │   │   └── libdd-common v3.0.1
        │   │       └── libdd-dogstatsd-client v1.0.1
        │   ├── libdd-common v3.0.1 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       └── libdd-common v3.0.1 (*)
        └── rustls-webpki v0.103.9
            └── rustls v0.23.37 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
  ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:5:1
  │
5 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
  │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
  │
  ├ ID: RUSTSEC-2026-0048
  ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
  ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
    certificate to bypass revocation checks during certificate validation, when
    the application enables CRL checking and uses partitioned CRLs with Issuing
    Distribution Point (IDP) extensions.
    
    Customers of AWS services do not need to take action. `aws-lc-sys` contains
    code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
    recent release of `aws-lc-sys`.
    
    ## Workarounds
    
    Applications can workaround this issue if they do not enable CRL checking
    (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
    CRLs without IDP extensions are also not affected.
    
    Otherwise, there is no workaround and applications using `aws-lc-sys` should
    upgrade to the most recent releases of `aws-lc-sys`.
  ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
  ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
  ├ aws-lc-sys v0.38.0
    └── aws-lc-rs v1.16.1
        ├── rustls v0.23.37
        │   ├── hyper-rustls v0.27.7
        │   │   └── libdd-common v3.0.1
        │   │       └── libdd-dogstatsd-client v1.0.1
        │   ├── libdd-common v3.0.1 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       └── libdd-common v3.0.1 (*)
        └── rustls-webpki v0.103.9
            └── rustls v0.23.37 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:84:1
   │
84 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0049
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
   ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
     
     The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
     
     This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
     
     More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
     
     This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
   ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
   ├ rustls-webpki v0.103.9
     └── rustls v0.23.37
         ├── hyper-rustls v0.27.7
         │   └── libdd-common v3.0.1
         │       └── libdd-dogstatsd-client v1.0.1
         ├── libdd-common v3.0.1 (*)
         └── tokio-rustls v0.26.0
             ├── hyper-rustls v0.27.7 (*)
             └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

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

Show output

error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:13:1
   │
13 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0044
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
   ├ A logic error in CN (Common Name) validation allows certificates with
     wildcard or raw UTF-8 Unicode CN values to bypass name constraints
     enforcement. The `cn2dnsid` function does not recognize these CN patterns
     as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
     validation. However, `X509_check_host` accepts these CN values when no
     dNSName SAN is present, allowing certificates to bypass name constraints
     while still being used for hostname verification.
     
     Customers of AWS services do not need to take action. Applications using
     `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
     fallback are not affected. Applications that only encounter certificates
     with dNSName SANs (standard for public WebPKI) are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   ├── libdd-common v3.0.1
         │   │   │   └── libdd-profiling v1.0.0
         │   │   │       └── (dev) libdd-profiling v1.0.0 (*)
         │   │   └── reqwest v0.13.2
         │   │       ├── libdd-common v3.0.1 (*)
         │   │       └── libdd-profiling v1.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   ├── libdd-profiling v1.0.0 (*)
         │   ├── reqwest v0.13.2 (*)
         │   ├── rustls-platform-verifier v0.6.2
         │   │   ├── libdd-profiling v1.0.0 (*)
         │   │   └── reqwest v0.13.2 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       ├── libdd-common v3.0.1 (*)
         │       └── reqwest v0.13.2 (*)
         └── rustls-webpki v0.103.9
             ├── rustls v0.23.37 (*)
             └── rustls-platform-verifier v0.6.2 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:13:1
   │
13 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0048
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
   ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
     certificate to bypass revocation checks during certificate validation, when
     the application enables CRL checking and uses partitioned CRLs with Issuing
     Distribution Point (IDP) extensions.
     
     Customers of AWS services do not need to take action. `aws-lc-sys` contains
     code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
     recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications can workaround this issue if they do not enable CRL checking
     (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
     CRLs without IDP extensions are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   ├── libdd-common v3.0.1
         │   │   │   └── libdd-profiling v1.0.0
         │   │   │       └── (dev) libdd-profiling v1.0.0 (*)
         │   │   └── reqwest v0.13.2
         │   │       ├── libdd-common v3.0.1 (*)
         │   │       └── libdd-profiling v1.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   ├── libdd-profiling v1.0.0 (*)
         │   ├── reqwest v0.13.2 (*)
         │   ├── rustls-platform-verifier v0.6.2
         │   │   ├── libdd-profiling v1.0.0 (*)
         │   │   └── reqwest v0.13.2 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       ├── libdd-common v3.0.1 (*)
         │       └── reqwest v0.13.2 (*)
         └── rustls-webpki v0.103.9
             ├── rustls v0.23.37 (*)
             └── rustls-platform-verifier v0.6.2 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:193:1
    │
193 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      ├── rustls v0.23.37
      │   ├── hyper-rustls v0.27.7
      │   │   ├── libdd-common v3.0.1
      │   │   │   └── libdd-profiling v1.0.0
      │   │   │       └── (dev) libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2
      │   │       ├── libdd-common v3.0.1 (*)
      │   │       └── libdd-profiling v1.0.0 (*)
      │   ├── libdd-common v3.0.1 (*)
      │   ├── libdd-profiling v1.0.0 (*)
      │   ├── reqwest v0.13.2 (*)
      │   ├── rustls-platform-verifier v0.6.2
      │   │   ├── libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2 (*)
      │   └── tokio-rustls v0.26.0
      │       ├── hyper-rustls v0.27.7 (*)
      │       ├── libdd-common v3.0.1 (*)
      │       └── reqwest v0.13.2 (*)
      └── rustls-platform-verifier v0.6.2 (*)

advisories FAILED, bans ok, sources ok

📦 `libdd-telemetry` - 3 error(s)

Show output

error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
  ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:6:1
  │
6 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
  │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
  │
  ├ ID: RUSTSEC-2026-0044
  ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
  ├ A logic error in CN (Common Name) validation allows certificates with
    wildcard or raw UTF-8 Unicode CN values to bypass name constraints
    enforcement. The `cn2dnsid` function does not recognize these CN patterns
    as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
    validation. However, `X509_check_host` accepts these CN values when no
    dNSName SAN is present, allowing certificates to bypass name constraints
    while still being used for hostname verification.
    
    Customers of AWS services do not need to take action. Applications using
    `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
    
    ## Workarounds
    
    Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
    fallback are not affected. Applications that only encounter certificates
    with dNSName SANs (standard for public WebPKI) are also not affected.
    
    Otherwise, there is no workaround and applications using `aws-lc-sys` should
    upgrade to the most recent releases of `aws-lc-sys`.
  ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
  ├ aws-lc-sys v0.38.0
    └── aws-lc-rs v1.16.1
        ├── rustls v0.23.37
        │   ├── hyper-rustls v0.27.7
        │   │   └── libdd-common v3.0.1
        │   │       └── libdd-telemetry v4.0.0
        │   ├── libdd-common v3.0.1 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       └── libdd-common v3.0.1 (*)
        └── rustls-webpki v0.103.9
            └── rustls v0.23.37 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
  ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:6:1
  │
6 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
  │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
  │
  ├ ID: RUSTSEC-2026-0048
  ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
  ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
    certificate to bypass revocation checks during certificate validation, when
    the application enables CRL checking and uses partitioned CRLs with Issuing
    Distribution Point (IDP) extensions.
    
    Customers of AWS services do not need to take action. `aws-lc-sys` contains
    code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
    recent release of `aws-lc-sys`.
    
    ## Workarounds
    
    Applications can workaround this issue if they do not enable CRL checking
    (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
    CRLs without IDP extensions are also not affected.
    
    Otherwise, there is no workaround and applications using `aws-lc-sys` should
    upgrade to the most recent releases of `aws-lc-sys`.
  ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
  ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
  ├ aws-lc-sys v0.38.0
    └── aws-lc-rs v1.16.1
        ├── rustls v0.23.37
        │   ├── hyper-rustls v0.27.7
        │   │   └── libdd-common v3.0.1
        │   │       └── libdd-telemetry v4.0.0
        │   ├── libdd-common v3.0.1 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       └── libdd-common v3.0.1 (*)
        └── rustls-webpki v0.103.9
            └── rustls v0.23.37 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:93:1
   │
93 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0049
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
   ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
     
     The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
     
     This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
     
     More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
     
     This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
   ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
   ├ rustls-webpki v0.103.9
     └── rustls v0.23.37
         ├── hyper-rustls v0.27.7
         │   └── libdd-common v3.0.1
         │       └── libdd-telemetry v4.0.0
         ├── libdd-common v3.0.1 (*)
         └── tokio-rustls v0.26.0
             ├── hyper-rustls v0.27.7 (*)
             └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

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

Show output

error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:24:1
   │
24 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0044
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
   ├ A logic error in CN (Common Name) validation allows certificates with
     wildcard or raw UTF-8 Unicode CN values to bypass name constraints
     enforcement. The `cn2dnsid` function does not recognize these CN patterns
     as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
     validation. However, `X509_check_host` accepts these CN values when no
     dNSName SAN is present, allowing certificates to bypass name constraints
     while still being used for hostname verification.
     
     Customers of AWS services do not need to take action. Applications using
     `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
     fallback are not affected. Applications that only encounter certificates
     with dNSName SANs (standard for public WebPKI) are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       ├── libdd-trace-obfuscation v1.0.1
         │   │       └── libdd-trace-utils v2.0.2
         │   │           ├── (dev) libdd-trace-obfuscation v1.0.1 (*)
         │   │           └── (dev) libdd-trace-utils v2.0.2 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:24:1
   │
24 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0048
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
   ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
     certificate to bypass revocation checks during certificate validation, when
     the application enables CRL checking and uses partitioned CRLs with Issuing
     Distribution Point (IDP) extensions.
     
     Customers of AWS services do not need to take action. `aws-lc-sys` contains
     code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
     recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications can workaround this issue if they do not enable CRL checking
     (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
     CRLs without IDP extensions are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       ├── libdd-trace-obfuscation v1.0.1
         │   │       └── libdd-trace-utils v2.0.2
         │   │           ├── (dev) libdd-trace-obfuscation v1.0.1 (*)
         │   │           └── (dev) libdd-trace-utils v2.0.2 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:218:1
    │
218 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       ├── libdd-trace-obfuscation v1.0.1
          │       └── libdd-trace-utils v2.0.2
          │           ├── (dev) libdd-trace-obfuscation v1.0.1 (*)
          │           └── (dev) libdd-trace-utils v2.0.2 (*)
          ├── libdd-common v3.0.1 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

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

Show output

error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:24:1
   │
24 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0044
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
   ├ A logic error in CN (Common Name) validation allows certificates with
     wildcard or raw UTF-8 Unicode CN values to bypass name constraints
     enforcement. The `cn2dnsid` function does not recognize these CN patterns
     as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
     validation. However, `X509_check_host` accepts these CN values when no
     dNSName SAN is present, allowing certificates to bypass name constraints
     while still being used for hostname verification.
     
     Customers of AWS services do not need to take action. Applications using
     `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
     fallback are not affected. Applications that only encounter certificates
     with dNSName SANs (standard for public WebPKI) are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       └── libdd-trace-utils v2.0.2
         │   │           └── (dev) libdd-trace-utils v2.0.2 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:24:1
   │
24 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0048
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
   ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
     certificate to bypass revocation checks during certificate validation, when
     the application enables CRL checking and uses partitioned CRLs with Issuing
     Distribution Point (IDP) extensions.
     
     Customers of AWS services do not need to take action. `aws-lc-sys` contains
     code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
     recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications can workaround this issue if they do not enable CRL checking
     (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
     CRLs without IDP extensions are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       └── libdd-trace-utils v2.0.2
         │   │           └── (dev) libdd-trace-utils v2.0.2 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:211:1
    │
211 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       └── libdd-trace-utils v2.0.2
          │           └── (dev) libdd-trace-utils v2.0.2 (*)
          ├── libdd-common v3.0.1 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-03-30 09:55:19 UTC | Commit: df910c7 | dependency-check job results

codecov-commenter · 2026-03-30T09:47:48Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.43%. Comparing base (5ff99ff) to head (a3f3182).

Additional details and impacted files

@@                                 Coverage Diff                                 @@
##           release-testing/libdd-telemetry/20260330-092705    #1818      +/-   ##
===================================================================================
+ Coverage                                            70.34%   70.43%   +0.09%     
===================================================================================
  Files                                                  410      410              
  Lines                                                62138    62138              
===================================================================================
+ Hits                                                 43710    43768      +58     
+ Misses                                               18428    18370      -58

Components	Coverage Δ
libdd-crashtracker	`65.06% <ø> (+0.24%)`	⬆️
libdd-crashtracker-ffi	`36.13% <ø> (+2.03%)`	⬆️
libdd-alloc	`98.77% <ø> (ø)`
libdd-data-pipeline	`87.42% <ø> (-0.54%)`	⬇️
libdd-data-pipeline-ffi	`72.40% <ø> (-3.03%)`	⬇️
libdd-common	`79.78% <ø> (ø)`
libdd-common-ffi	`73.87% <ø> (ø)`
libdd-telemetry	`62.48% <ø> (ø)`
libdd-telemetry-ffi	`16.75% <ø> (ø)`
libdd-dogstatsd-client	`82.64% <ø> (ø)`
datadog-ipc	`72.56% <ø> (+2.24%)`	⬆️
libdd-profiling	`81.61% <ø> (ø)`
libdd-profiling-ffi	`64.94% <ø> (ø)`
datadog-sidecar	`31.33% <ø> (+0.65%)`	⬆️
datdog-sidecar-ffi	`11.91% <ø> (+3.07%)`	⬆️
spawn-worker	`54.69% <ø> (ø)`
libdd-tinybytes	`93.16% <ø> (ø)`
libdd-trace-normalization	`81.71% <ø> (ø)`
libdd-trace-obfuscation	`92.26% <ø> (ø)`
libdd-trace-protobuf	`68.25% <ø> (ø)`
libdd-trace-utils	`88.95% <ø> (ø)`
datadog-tracer-flare	`86.88% <ø> (ø)`
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.

datadog-datadog-prod-us1-2 · 2026-03-30T09:48:12Z

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 70.44% (+0.09%)

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

🔗 Commit SHA: a3f3182 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!}

pr-commenter · 2026-03-30T09:48:49Z

Benchmarks

Comparison

Benchmark execution time: 2026-03-30 09:49:44

Comparing candidate commit a3f3182 in PR branch release-proposal-testing/libdd-telemetry/20260330-092705 with baseline commit 5ff99ff in branch release-testing/libdd-telemetry/20260330-092705.

Found 5 performance improvements and 15 performance regressions! Performance is the same for 41 metrics, 0 unstable metrics.

Explanation

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

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

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

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

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

More details about the CI and significant changes

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

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

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

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

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

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

scenario:benching serializing traces from their internal representation to msgpack

🟩 execution_time [-624.784µs; -613.645µs] or [-4.243%; -4.167%]

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

🟥 execution_time [+3.375µs; +3.630µs] or [+4.441%; +4.777%]
🟥 throughput [-602973.870op/s; -559524.656op/s] or [-4.582%; -4.252%]

scenario:credit_card/is_card_number/ 378282246310005

🟥 execution_time [+4.309µs; +4.393µs] or [+6.281%; +6.404%]
🟥 throughput [-877241.876op/s; -861257.773op/s] or [-6.018%; -5.908%]

scenario:credit_card/is_card_number/378282246310005

🟥 execution_time [+4.756µs; +4.838µs] or [+7.324%; +7.451%]
🟥 throughput [-1067929.145op/s; -1050686.643op/s] or [-6.934%; -6.822%]

scenario:credit_card/is_card_number/37828224631000521389798

🟥 execution_time [+6.496µs; +6.548µs] or [+14.217%; +14.329%]
🟥 throughput [-2745853.998op/s; -2721514.069op/s] or [-12.547%; -12.436%]

scenario:credit_card/is_card_number/x371413321323331

🟩 execution_time [-399.514ns; -396.531ns] or [-6.207%; -6.161%]
🟩 throughput [+10201683.490op/s; +10282021.294op/s] or [+6.566%; +6.618%]

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

🟥 execution_time [+3.680µs; +3.742µs] or [+6.788%; +6.901%]
🟥 throughput [-1191505.386op/s; -1171509.790op/s] or [-6.461%; -6.352%]

scenario:credit_card/is_card_number_no_luhn/378282246310005

🟥 execution_time [+4.253µs; +4.330µs] or [+8.425%; +8.578%]
🟥 throughput [-1566122.863op/s; -1538304.264op/s] or [-7.906%; -7.765%]

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

🟥 execution_time [+6.451µs; +6.478µs] or [+14.096%; +14.156%]
🟥 throughput [-2711069.618op/s; -2698300.956op/s] or [-12.407%; -12.348%]

scenario:credit_card/is_card_number_no_luhn/x371413321323331

🟩 execution_time [-401.324ns; -397.719ns] or [-6.234%; -6.178%]
🟩 throughput [+10230002.510op/s; +10326977.404op/s] or [+6.586%; +6.648%]

scenario:receiver_entry_point/report/2598

🟥 execution_time [+191.984µs; +199.239µs] or [+5.630%; +5.842%]

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	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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	160.799µs	161.328µs ± 0.337µs	161.251µs ± 0.133µs	161.399µs	162.001µs	162.345µs	164.061µs	1.74%	3.509	21.483	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	[161.281µs; 161.375µs] or [-0.029%; +0.029%]	None	None	None

Group 2

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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.894µs	3.912µs ± 0.003µs	3.912µs ± 0.001µs	3.914µs	3.917µs	3.920µs	3.929µs	0.44%	0.274	12.032	0.07%	0.000µs	1	200
credit_card/is_card_number/	throughput	254502610.195op/s	255604001.723op/s ± 189405.776op/s	255626482.942op/s ± 96647.745op/s	255719280.259op/s	255812541.851op/s	255846946.550op/s	256782534.930op/s	0.45%	-0.243	12.071	0.07%	13393.011op/s	1	200
credit_card/is_card_number/ 3782-8224-6310-005	execution_time	78.700µs	79.501µs ± 0.317µs	79.448µs ± 0.195µs	79.723µs	80.075µs	80.293µs	80.397µs	1.19%	0.400	-0.151	0.40%	0.022µs	1	200
credit_card/is_card_number/ 3782-8224-6310-005	throughput	12438268.921op/s	12578699.455op/s ± 50154.074op/s	12586849.261op/s ± 30869.983op/s	12611437.675op/s	12646455.032op/s	12674373.647op/s	12706467.491op/s	0.95%	-0.380	-0.166	0.40%	3546.429op/s	1	200
credit_card/is_card_number/ 378282246310005	execution_time	72.405µs	72.951µs ± 0.296µs	72.892µs ± 0.182µs	73.132µs	73.495µs	73.749µs	74.128µs	1.70%	0.841	0.924	0.40%	0.021µs	1	200
credit_card/is_card_number/ 378282246310005	throughput	13490154.094op/s	13708069.514op/s ± 55385.741op/s	13718885.716op/s ± 34260.069op/s	13748250.554op/s	13787242.322op/s	13801323.191op/s	13811129.008op/s	0.67%	-0.815	0.847	0.40%	3916.363op/s	1	200
credit_card/is_card_number/37828224631	execution_time	3.892µs	3.913µs ± 0.003µs	3.913µs ± 0.002µs	3.914µs	3.917µs	3.919µs	3.920µs	0.20%	-1.617	13.039	0.07%	0.000µs	1	200
credit_card/is_card_number/37828224631	throughput	255075208.267op/s	255576253.728op/s ± 181781.889op/s	255581955.914op/s ± 111039.629op/s	255685155.941op/s	255797204.297op/s	255858708.985op/s	256910345.526op/s	0.52%	1.644	13.257	0.07%	12853.921op/s	1	200
credit_card/is_card_number/378282246310005	execution_time	69.184µs	69.728µs ± 0.276µs	69.691µs ± 0.180µs	69.881µs	70.262µs	70.434µs	70.625µs	1.34%	0.639	0.147	0.40%	0.020µs	1	200
credit_card/is_card_number/378282246310005	throughput	14159212.677op/s	14341731.547op/s ± 56672.083op/s	14349134.471op/s ± 36915.570op/s	14382880.421op/s	14424776.864op/s	14437270.980op/s	14454158.286op/s	0.73%	-0.619	0.111	0.39%	4007.321op/s	1	200
credit_card/is_card_number/37828224631000521389798	execution_time	52.151µs	52.217µs ± 0.036µs	52.210µs ± 0.020µs	52.235µs	52.285µs	52.325µs	52.349µs	0.27%	0.895	0.750	0.07%	0.003µs	1	200
credit_card/is_card_number/37828224631000521389798	throughput	19102483.731op/s	19150724.520op/s ± 13109.142op/s	19153579.385op/s ± 7409.696op/s	19160099.094op/s	19168538.199op/s	19171812.585op/s	19175256.249op/s	0.11%	-0.891	0.739	0.07%	926.956op/s	1	200
credit_card/is_card_number/x371413321323331	execution_time	6.028µs	6.038µs ± 0.010µs	6.037µs ± 0.003µs	6.040µs	6.044µs	6.081µs	6.113µs	1.26%	4.719	27.545	0.17%	0.001µs	1	200
credit_card/is_card_number/x371413321323331	throughput	163580969.172op/s	165610942.704op/s ± 278538.959op/s	165646571.535op/s ± 86409.272op/s	165740834.133op/s	165839000.538op/s	165858486.314op/s	165888413.596op/s	0.15%	-4.682	27.170	0.17%	19695.679op/s	1	200
credit_card/is_card_number_no_luhn/	execution_time	3.894µs	3.913µs ± 0.003µs	3.913µs ± 0.002µs	3.915µs	3.917µs	3.919µs	3.920µs	0.19%	-1.287	7.851	0.07%	0.000µs	1	200
credit_card/is_card_number_no_luhn/	throughput	255070320.971op/s	255545715.584op/s ± 187898.406op/s	255544355.233op/s ± 120514.214op/s	255654153.958op/s	255824119.837op/s	255863586.065op/s	256781838.411op/s	0.48%	1.305	7.985	0.07%	13286.424op/s	1	200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	execution_time	63.797µs	64.398µs ± 0.222µs	64.372µs ± 0.133µs	64.516µs	64.768µs	64.903µs	65.597µs	1.90%	0.866	3.618	0.34%	0.016µs	1	200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	throughput	15244653.231op/s	15528527.511op/s ± 53466.760op/s	15534720.000op/s ± 32191.766op/s	15565396.180op/s	15594586.652op/s	15660665.356op/s	15674745.022op/s	0.90%	-0.817	3.404	0.34%	3780.671op/s	1	200
credit_card/is_card_number_no_luhn/ 378282246310005	execution_time	57.790µs	57.934µs ± 0.131µs	57.885µs ± 0.056µs	57.993µs	58.198µs	58.367µs	58.534µs	1.12%	1.628	2.918	0.23%	0.009µs	1	200
credit_card/is_card_number_no_luhn/ 378282246310005	throughput	17083946.166op/s	17261188.310op/s ± 38938.486op/s	17275600.805op/s ± 16647.944op/s	17288069.506op/s	17300751.026op/s	17303532.014op/s	17304094.149op/s	0.16%	-1.612	2.840	0.23%	2753.367op/s	1	200
credit_card/is_card_number_no_luhn/37828224631	execution_time	3.893µs	3.913µs ± 0.003µs	3.912µs ± 0.002µs	3.914µs	3.918µs	3.921µs	3.930µs	0.46%	0.255	10.747	0.08%	0.000µs	1	200
credit_card/is_card_number_no_luhn/37828224631	throughput	254450089.157op/s	255589490.081op/s ± 204911.804op/s	255625537.003op/s ± 104373.794op/s	255715960.796op/s	255785879.606op/s	255875593.887op/s	256854425.644op/s	0.48%	-0.224	10.805	0.08%	14489.453op/s	1	200
credit_card/is_card_number_no_luhn/378282246310005	execution_time	54.466µs	54.771µs ± 0.200µs	54.704µs ± 0.081µs	54.829µs	55.106µs	55.650µs	55.753µs	1.92%	2.173	6.345	0.36%	0.014µs	1	200
credit_card/is_card_number_no_luhn/378282246310005	throughput	17936120.946op/s	18258182.121op/s ± 66228.641op/s	18280246.368op/s ± 27221.663op/s	18303135.327op/s	18317012.292op/s	18322644.805op/s	18359993.113op/s	0.44%	-2.134	6.107	0.36%	4683.072op/s	1	200
credit_card/is_card_number_no_luhn/37828224631000521389798	execution_time	52.154µs	52.228µs ± 0.037µs	52.227µs ± 0.024µs	52.250µs	52.291µs	52.309µs	52.403µs	0.34%	0.595	1.548	0.07%	0.003µs	1	200
credit_card/is_card_number_no_luhn/37828224631000521389798	throughput	19082783.999op/s	19146787.107op/s ± 13456.817op/s	19147218.780op/s ± 8908.899op/s	19156753.634op/s	19168140.251op/s	19170090.922op/s	19174141.752op/s	0.14%	-0.589	1.520	0.07%	951.541op/s	1	200
credit_card/is_card_number_no_luhn/x371413321323331	execution_time	6.029µs	6.038µs ± 0.012µs	6.035µs ± 0.003µs	6.039µs	6.052µs	6.081µs	6.150µs	1.90%	5.359	37.166	0.21%	0.001µs	1	200
credit_card/is_card_number_no_luhn/x371413321323331	throughput	162605407.704op/s	165613297.854op/s ± 338494.916op/s	165693894.180op/s ± 76914.821op/s	165757049.433op/s	165821033.608op/s	165845231.833op/s	165858394.767op/s	0.10%	-5.296	36.299	0.20%	23935.205op/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.912µs; 3.913µs] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number/	throughput	[255577751.904op/s; 255630251.542op/s] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number/ 3782-8224-6310-005	execution_time	[79.457µs; 79.545µs] or [-0.055%; +0.055%]	None	None	None
credit_card/is_card_number/ 3782-8224-6310-005	throughput	[12571748.583op/s; 12585650.327op/s] or [-0.055%; +0.055%]	None	None	None
credit_card/is_card_number/ 378282246310005	execution_time	[72.910µs; 72.992µs] or [-0.056%; +0.056%]	None	None	None
credit_card/is_card_number/ 378282246310005	throughput	[13700393.583op/s; 13715745.445op/s] or [-0.056%; +0.056%]	None	None	None
credit_card/is_card_number/37828224631	execution_time	[3.912µs; 3.913µs] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number/37828224631	throughput	[255551060.506op/s; 255601446.949op/s] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number/378282246310005	execution_time	[69.689µs; 69.766µs] or [-0.055%; +0.055%]	None	None	None
credit_card/is_card_number/378282246310005	throughput	[14333877.341op/s; 14349585.753op/s] or [-0.055%; +0.055%]	None	None	None
credit_card/is_card_number/37828224631000521389798	execution_time	[52.212µs; 52.222µs] or [-0.009%; +0.009%]	None	None	None
credit_card/is_card_number/37828224631000521389798	throughput	[19148907.719op/s; 19152541.321op/s] or [-0.009%; +0.009%]	None	None	None
credit_card/is_card_number/x371413321323331	execution_time	[6.037µs; 6.040µs] or [-0.023%; +0.023%]	None	None	None
credit_card/is_card_number/x371413321323331	throughput	[165572339.883op/s; 165649545.525op/s] or [-0.023%; +0.023%]	None	None	None
credit_card/is_card_number_no_luhn/	execution_time	[3.913µs; 3.914µs] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number_no_luhn/	throughput	[255519674.672op/s; 255571756.496op/s] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	execution_time	[64.368µs; 64.429µs] or [-0.048%; +0.048%]	None	None	None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	throughput	[15521117.532op/s; 15535937.490op/s] or [-0.048%; +0.048%]	None	None	None
credit_card/is_card_number_no_luhn/ 378282246310005	execution_time	[57.916µs; 57.952µs] or [-0.031%; +0.031%]	None	None	None
credit_card/is_card_number_no_luhn/ 378282246310005	throughput	[17255791.810op/s; 17266584.810op/s] or [-0.031%; +0.031%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631	execution_time	[3.912µs; 3.913µs] or [-0.011%; +0.011%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631	throughput	[255561091.276op/s; 255617888.887op/s] or [-0.011%; +0.011%]	None	None	None
credit_card/is_card_number_no_luhn/378282246310005	execution_time	[54.743µs; 54.798µs] or [-0.051%; +0.051%]	None	None	None
credit_card/is_card_number_no_luhn/378282246310005	throughput	[18249003.468op/s; 18267360.774op/s] or [-0.050%; +0.050%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631000521389798	execution_time	[52.223µs; 52.233µs] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631000521389798	throughput	[19144922.121op/s; 19148652.092op/s] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number_no_luhn/x371413321323331	execution_time	[6.036µs; 6.040µs] or [-0.029%; +0.029%]	None	None	None
credit_card/is_card_number_no_luhn/x371413321323331	throughput	[165566385.714op/s; 165660209.994op/s] or [-0.028%; +0.028%]	None	None	None

Group 3

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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.568ms	3.606ms ± 0.020ms	3.601ms ± 0.009ms	3.613ms	3.641ms	3.658ms	3.761ms	4.42%	2.787	15.997	0.56%	0.001ms	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.603ms; 3.609ms] or [-0.078%; +0.078%]	None	None	None

Group 4

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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.168ms	4.172ms ± 0.002ms	4.171ms ± 0.002ms	4.173ms	4.175ms	4.176ms	4.182ms	0.26%	0.736	1.398	0.05%	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	[4.171ms; 4.172ms] or [-0.007%; +0.007%]	None	None	None

Group 5

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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	185.412µs	185.971µs ± 0.465µs	185.862µs ± 0.148µs	186.028µs	186.686µs	187.897µs	188.975µs	1.67%	3.264	13.440	0.25%	0.033µs	1	200
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...	throughput	5291712.953op/s	5377223.614op/s ± 13350.179op/s	5380329.073op/s ± 4267.880op/s	5384221.767op/s	5388543.708op/s	5389879.922op/s	5393397.080op/s	0.24%	-3.228	13.152	0.25%	944.000op/s	1	200
normalization/normalize_name/normalize_name/bad-name	execution_time	17.910µs	17.987µs ± 0.049µs	17.985µs ± 0.031µs	18.011µs	18.066µs	18.117µs	18.298µs	1.74%	1.660	7.327	0.27%	0.003µs	1	200
normalization/normalize_name/normalize_name/bad-name	throughput	54651534.468op/s	55595751.883op/s ± 150802.458op/s	55600903.258op/s ± 96105.024op/s	55700104.089op/s	55798429.834op/s	55823883.399op/s	55834152.860op/s	0.42%	-1.607	6.943	0.27%	10663.344op/s	1	200
normalization/normalize_name/normalize_name/good	execution_time	10.106µs	10.219µs ± 0.045µs	10.223µs ± 0.035µs	10.254µs	10.285µs	10.304µs	10.312µs	0.87%	-0.121	-0.876	0.44%	0.003µs	1	200
normalization/normalize_name/normalize_name/good	throughput	96977319.797op/s	97856860.848op/s ± 428810.571op/s	97818897.949op/s ± 335964.939op/s	98203161.145op/s	98529653.953op/s	98665188.311op/s	98955346.400op/s	1.16%	0.135	-0.870	0.44%	30321.486op/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	[185.906µs; 186.035µs] or [-0.035%; +0.035%]	None	None	None
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...	throughput	[5375373.408op/s; 5379073.821op/s] or [-0.034%; +0.034%]	None	None	None
normalization/normalize_name/normalize_name/bad-name	execution_time	[17.980µs; 17.994µs] or [-0.038%; +0.038%]	None	None	None
normalization/normalize_name/normalize_name/bad-name	throughput	[55574852.112op/s; 55616651.653op/s] or [-0.038%; +0.038%]	None	None	None
normalization/normalize_name/normalize_name/good	execution_time	[10.213µs; 10.225µs] or [-0.061%; +0.061%]	None	None	None
normalization/normalize_name/normalize_name/good	throughput	[97797431.827op/s; 97916289.869op/s] or [-0.061%; +0.061%]	None	None	None

Group 6

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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.958µs	5.062µs ± 0.057µs	5.085µs ± 0.052µs	5.115µs	5.137µs	5.142µs	5.145µs	1.19%	-0.154	-1.596	1.11%	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.054µs; 5.070µs] or [-0.155%; +0.155%]	None	None	None

Group 7

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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	145.211µs	146.961µs ± 1.615µs	146.746µs ± 0.450µs	147.188µs	148.690µs	153.314µs	162.684µs	10.86%	5.881	47.878	1.10%	0.114µ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.737µs; 147.185µs] or [-0.152%; +0.152%]	None	None	None

Group 8

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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	13.002ms	13.031ms ± 0.014ms	13.028ms ± 0.009ms	13.038ms	13.060ms	13.071ms	13.090ms	0.48%	0.969	1.300	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.029ms; 13.033ms] or [-0.015%; +0.015%]	None	None	None

Group 9

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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	13.766µs	13.870µs ± 0.091µs	13.855µs ± 0.030µs	13.892µs	13.962µs	14.027µs	14.920µs	7.69%	7.891	87.355	0.65%	0.006µs	1	200

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

Group 10

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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	238.291ns	249.243ns ± 12.971ns	243.827ns ± 4.116ns	252.098ns	283.026ns	284.688ns	286.937ns	17.68%	1.601	1.489	5.19%	0.917ns	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	[247.446ns; 251.041ns] or [-0.721%; +0.721%]	None	None	None

Group 11

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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_timestamped_x1000	execution_time	4.177ms	4.181ms ± 0.008ms	4.180ms ± 0.001ms	4.181ms	4.183ms	4.186ms	4.284ms	2.50%	12.573	167.247	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_timestamped_x1000	execution_time	[4.180ms; 4.182ms] or [-0.025%; +0.025%]	None	None	None

Group 12

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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	730.308µs	731.800µs ± 0.540µs	731.824µs ± 0.337µs	732.108µs	732.745µs	732.950µs	733.515µs	0.23%	0.092	0.124	0.07%	0.038µ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	[731.725µs; 731.875µs] or [-0.010%; +0.010%]	None	None	None

Group 13

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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.775ms	50.244ms ± 1.382ms	50.078ms ± 0.093ms	50.158ms	50.375ms	55.847ms	63.871ms	27.54%	8.757	78.362	2.74%	0.098ms	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	[50.052ms; 50.435ms] or [-0.381%; +0.381%]	None	None	None

Group 14

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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.552ns	193.143ns ± 1.977ns	192.727ns ± 1.228ns	194.174ns	196.964ns	198.402ns	200.587ns	4.08%	0.910	0.558	1.02%	0.140ns	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	[192.869ns; 193.417ns] or [-0.142%; +0.142%]	None	None	None

Group 15

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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.069µs	85.339µs ± 0.248µs	85.312µs ± 0.069µs	85.383µs	85.554µs	85.702µs	88.439µs	3.67%	9.890	120.884	0.29%	0.018µ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.304µs; 85.373µs] or [-0.040%; +0.040%]	None	None	None

Group 16

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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	34.376µs	34.951µs ± 0.950µs	34.524µs ± 0.063µs	34.622µs	36.941µs	36.964µs	38.714µs	12.14%	1.783	1.545	2.71%	0.067µ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.819µs; 35.082µs] or [-0.377%; +0.377%]	None	None	None

Group 17

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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.049ms	14.106ms ± 0.028ms	14.104ms ± 0.010ms	14.114ms	14.138ms	14.232ms	14.276ms	1.22%	2.963	13.011	0.20%	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.103ms; 14.110ms] or [-0.027%; +0.027%]	None	None	None

Group 18

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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	495.358µs	496.310µs ± 0.743µs	496.208µs ± 0.268µs	496.478µs	496.998µs	499.469µs	502.557µs	1.28%	5.206	37.245	0.15%	0.053µs	1	200
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...	throughput	1989826.020op/s	2014874.066op/s ± 2991.247op/s	2015283.913op/s ± 1089.236op/s	2016347.086op/s	2017573.570op/s	2018331.781op/s	2018742.454op/s	0.17%	-5.152	36.660	0.15%	211.513op/s	1	200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	execution_time	370.220µs	370.961µs ± 0.307µs	370.976µs ± 0.213µs	371.147µs	371.470µs	371.576µs	371.987µs	0.27%	0.225	-0.238	0.08%	0.022µs	1	200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	throughput	2688269.130op/s	2695701.316op/s ± 2227.121op/s	2695595.643op/s ± 1549.750op/s	2697355.378op/s	2698946.014op/s	2700344.141op/s	2701095.059op/s	0.20%	-0.220	-0.243	0.08%	157.481op/s	1	200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	execution_time	168.241µs	168.763µs ± 0.182µs	168.740µs ± 0.123µs	168.890µs	169.063µs	169.195µs	169.294µs	0.33%	0.281	0.094	0.11%	0.013µs	1	200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	throughput	5906887.940op/s	5925483.231op/s ± 6385.479op/s	5926269.354op/s ± 4323.220op/s	5929899.214op/s	5934698.320op/s	5940432.690op/s	5943855.995op/s	0.30%	-0.274	0.093	0.11%	451.522op/s	1	200
normalization/normalize_service/normalize_service/[empty string]	execution_time	38.260µs	38.384µs ± 0.102µs	38.378µs ± 0.031µs	38.410µs	38.441µs	38.489µs	39.696µs	3.44%	10.532	132.752	0.27%	0.007µs	1	200
normalization/normalize_service/normalize_service/[empty string]	throughput	25191420.652op/s	26052756.631op/s ± 67684.771op/s	26056760.572op/s ± 20954.003op/s	26076800.025op/s	26102054.284op/s	26128682.309op/s	26136747.779op/s	0.31%	-10.342	129.549	0.26%	4786.036op/s	1	200
normalization/normalize_service/normalize_service/test_ASCII	execution_time	46.186µs	46.311µs ± 0.130µs	46.289µs ± 0.042µs	46.335µs	46.451µs	46.572µs	47.786µs	3.23%	7.731	82.014	0.28%	0.009µs	1	200
normalization/normalize_service/normalize_service/test_ASCII	throughput	20926791.804op/s	21593300.762op/s ± 59354.781op/s	21603627.682op/s ± 19697.832op/s	21619851.782op/s	21638895.829op/s	21650943.527op/s	21651759.831op/s	0.22%	-7.529	78.823	0.27%	4197.017op/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	[496.207µs; 496.413µs] or [-0.021%; +0.021%]	None	None	None
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...	throughput	[2014459.508op/s; 2015288.624op/s] or [-0.021%; +0.021%]	None	None	None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	execution_time	[370.919µs; 371.004µs] or [-0.011%; +0.011%]	None	None	None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	throughput	[2695392.658op/s; 2696009.973op/s] or [-0.011%; +0.011%]	None	None	None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	execution_time	[168.738µs; 168.788µs] or [-0.015%; +0.015%]	None	None	None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	throughput	[5924598.265op/s; 5926368.197op/s] or [-0.015%; +0.015%]	None	None	None
normalization/normalize_service/normalize_service/[empty string]	execution_time	[38.370µs; 38.398µs] or [-0.037%; +0.037%]	None	None	None
normalization/normalize_service/normalize_service/[empty string]	throughput	[26043376.172op/s; 26062137.089op/s] or [-0.036%; +0.036%]	None	None	None
normalization/normalize_service/normalize_service/test_ASCII	execution_time	[46.293µs; 46.329µs] or [-0.039%; +0.039%]	None	None	None
normalization/normalize_service/normalize_service/test_ASCII	throughput	[21585074.760op/s; 21601526.763op/s] or [-0.038%; +0.038%]	None	None	None

Group 19

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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.330µs	2.378µs ± 0.026µs	2.373µs ± 0.018µs	2.394µs	2.430µs	2.445µs	2.454µs	3.42%	0.753	-0.048	1.11%	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.374µs; 2.382µs] or [-0.154%; +0.154%]	None	None	None

Group 20

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`a3f3182`	1774863137	release-proposal-testing/libdd-telemetry/20260330-092705

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	5.354µs	5.416µs ± 0.036µs	5.425µs ± 0.024µs	5.442µs	5.456µs	5.485µs	5.645µs	4.06%	1.153	6.661	0.66%	0.003µs	1	200

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

Baseline

Omitted due to size.

github-actions bot and others added 5 commits March 30, 2026 09:32

chore: Release

b42c180

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore: Release

d63cec5

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update version for libdd-telemetry with major bumps

adfe551

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-common

bb66e69

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-telemetry

a3f3182

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

dd-octo-sts bot added skip-changelog-check skip-metadata-check release-proposal This is a release proposal PR labels Mar 30, 2026

github-actions bot added telemetry mini-agent common data-pipeline crashtracker labels Mar 30, 2026

iunanua added the skip-pr-title-semver-check label Mar 30, 2026

iunanua closed this Mar 30, 2026

iunanua deleted the release-proposal-testing/libdd-telemetry/20260330-092705 branch March 30, 2026 10:05

iunanua mentioned this pull request Apr 8, 2026

ci: check major bumps in proposal workflow #1851

Draft

Conversation

dd-octo-sts bot commented Mar 30, 2026

Release proposal for libdd-telemetry and its dependencies

Cut from non-default ref

Non-default workflow options

libdd-common

Commits

libdd-telemetry

libdd dependency major bumps

Commits

Uh oh!

github-actions bot commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📚 Documentation Check Results

📦 libdd-common - 166 warning(s)

📦 libdd-crashtracker - 1049 warning(s)

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

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

📦 libdd-profiling - 647 warning(s)

📦 libdd-telemetry - 476 warning(s)

📦 libdd-trace-obfuscation - 522 warning(s)

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

Uh oh!

github-actions bot commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔒 Cargo Deny Results

📦 libdd-common - 3 error(s)

📦 libdd-crashtracker - 4 error(s)

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

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

📦 libdd-profiling - 3 error(s)

📦 libdd-telemetry - 3 error(s)

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

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

Uh oh!

codecov-commenter commented Mar 30, 2026

Codecov Report

Uh oh!

datadog-datadog-prod-us1-2 bot commented Mar 30, 2026

Uh oh!

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

Uh oh!

Benchmarks

Comparison

Explanation

More details about the CI and significant changes

scenario:benching serializing traces from their internal representation to msgpack

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

scenario:credit_card/is_card_number/ 378282246310005

scenario:credit_card/is_card_number/378282246310005

scenario:credit_card/is_card_number/37828224631000521389798

scenario:credit_card/is_card_number/x371413321323331

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

scenario:credit_card/is_card_number_no_luhn/378282246310005

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

scenario:credit_card/is_card_number_no_luhn/x371413321323331

scenario:receiver_entry_point/report/2598

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

Group 20

Baseline

Uh oh!

github-actions bot commented Mar 30, 2026 •

edited

Loading

📦 `libdd-common` - 166 warning(s)

📦 `libdd-crashtracker` - 1049 warning(s)

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

📦 `libdd-dogstatsd-client` - 166 warning(s)

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

📦 `libdd-telemetry` - 476 warning(s)

📦 `libdd-trace-obfuscation` - 522 warning(s)

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

github-actions bot commented Mar 30, 2026 •

edited

Loading

📦 `libdd-common` - 3 error(s)

📦 `libdd-crashtracker` - 4 error(s)

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

📦 `libdd-dogstatsd-client` - 3 error(s)

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

📦 `libdd-telemetry` - 3 error(s)

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

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

pr-commenter bot commented Mar 30, 2026 •

edited

Loading