Skip to content

feat: single source of truth for headers (fixes issue in profiling with missing headers)#1493

Merged
gh-worker-dd-mergequeue-cf854d[bot] merged 6 commits intomainfrom
dsn/fix-headers
Feb 4, 2026
Merged

feat: single source of truth for headers (fixes issue in profiling with missing headers)#1493
gh-worker-dd-mergequeue-cf854d[bot] merged 6 commits intomainfrom
dsn/fix-headers

Conversation

@danielsn
Copy link
Copy Markdown
Contributor

What does this PR do?

Unifies the headers between common and profiling

Motivation

We had missed some when we implemented our own exporter, this makes sure the two implementations stay in sync.

Additional Notes

Anything else we should know when reviewing?

How to test the change?

Describe here in detail how the change can be validated.

@danielsn danielsn requested review from a team as code owners January 30, 2026 02:32
@github-actions
Copy link
Copy Markdown

github-actions bot commented Jan 30, 2026

📚 Documentation Check Results

⚠️ 747 documentation warning(s) found

📦 libdd-common - 155 warning(s)

📦 libdd-profiling - 592 warning(s)


Updated: 2026-02-04 19:06:26 UTC | Commit: 4ee280f | missing-docs job results

@github-actions
Copy link
Copy Markdown

github-actions bot commented Jan 30, 2026

🔒 Cargo Deny Results

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

📦 libdd-common - 6 error(s)

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

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

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

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

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

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

advisories FAILED, bans ok, sources ok

📦 libdd-profiling - 6 error(s)

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

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

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

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

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

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

advisories FAILED, bans ok, sources ok

Updated: 2026-02-04 19:06:23 UTC | Commit: 4ee280f | dependency-check job results

@pr-commenter
Copy link
Copy Markdown

pr-commenter bot commented Jan 30, 2026

Benchmarks

Comparison

Benchmark execution time: 2026-02-04 18:53:04

Comparing candidate commit 7ac277e in PR branch dsn/fix-headers with baseline commit b44bb77 in branch main.

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

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 7ac277e 1770230202 dsn/fix-headers
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
ip_address/quantize_peer_ip_address_benchmark execution_time 5.008µs 5.077µs ± 0.044µs 5.063µs ± 0.028µs 5.122µs 5.155µs 5.157µs 5.159µs 1.91% 0.570 -1.184 0.87% 0.003µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
ip_address/quantize_peer_ip_address_benchmark execution_time [5.070µs; 5.083µs] or [-0.121%; +0.121%] None None None

Group 2

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
profile_add_sample_frames_x1000 execution_time 3.913ms 3.918ms ± 0.006ms 3.917ms ± 0.001ms 3.919ms 3.921ms 3.925ms 3.998ms 2.05% 11.482 147.583 0.15% 0.000ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profile_add_sample_frames_x1000 execution_time [3.917ms; 3.919ms] or [-0.021%; +0.021%] None None None

Group 3

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
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 161.337µs 162.169µs ± 0.294µs 162.116µs ± 0.130µs 162.264µs 162.676µs 163.197µs 163.665µs 0.96% 1.820 6.633 0.18% 0.021µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
benching string interning on wordpress profile execution_time [162.128µs; 162.210µs] or [-0.025%; +0.025%] None None None

Group 4

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
benching deserializing traces from msgpack to their internal representation execution_time 48.388ms 48.734ms ± 1.224ms 48.581ms ± 0.036ms 48.624ms 48.783ms 52.536ms 61.290ms 26.16% 9.184 85.664 2.51% 0.087ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
benching deserializing traces from msgpack to their internal representation execution_time [48.564ms; 48.904ms] or [-0.348%; +0.348%] None None None

Group 5

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
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 540.010µs 540.753µs ± 0.440µs 540.638µs ± 0.225µs 540.920µs 541.717µs 542.030µs 542.701µs 0.38% 1.362 2.111 0.08% 0.031µ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 [540.692µs; 540.814µs] or [-0.011%; +0.011%] None None None

Group 6

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
redis/obfuscate_redis_string execution_time 33.076µs 33.727µs ± 1.171µs 33.193µs ± 0.052µs 33.279µs 36.246µs 36.307µs 37.163µs 11.96% 1.708 0.981 3.46% 0.083µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
redis/obfuscate_redis_string execution_time [33.565µs; 33.889µs] or [-0.481%; +0.481%] None None None

Group 7

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
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 240.602ns 254.310ns ± 15.638ns 246.251ns ± 3.895ns 267.843ns 287.683ns 292.721ns 299.935ns 21.80% 1.180 0.018 6.13% 1.106ns 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 [252.142ns; 256.477ns] or [-0.852%; +0.852%] None None None

Group 8

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
concentrator/add_spans_to_concentrator execution_time 10.628ms 10.662ms ± 0.017ms 10.660ms ± 0.010ms 10.670ms 10.689ms 10.709ms 10.763ms 0.96% 1.523 5.745 0.16% 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 [10.660ms; 10.665ms] or [-0.022%; +0.022%] None None None

Group 9

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
write only interface execution_time 1.181µs 3.262µs ± 1.454µs 3.012µs ± 0.033µs 3.056µs 3.702µs 14.397µs 14.963µs 396.80% 7.252 54.108 44.46% 0.103µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
write only interface execution_time [3.061µs; 3.464µs] or [-6.177%; +6.177%] None None None

Group 10

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
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 205.105µs 205.936µs ± 0.522µs 205.868µs ± 0.325µs 206.223µs 206.758µs 207.027µs 209.617µs 1.82% 1.949 10.894 0.25% 0.037µs 1 200
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo... throughput 4770606.053op/s 4855901.244op/s ± 12240.733op/s 4857483.090op/s ± 7676.215op/s 4864340.927op/s 4872068.149op/s 4874528.318op/s 4875558.614op/s 0.37% -1.882 10.300 0.25% 865.551op/s 1 200
normalization/normalize_name/normalize_name/bad-name execution_time 18.585µs 18.650µs ± 0.033µs 18.647µs ± 0.020µs 18.673µs 18.698µs 18.718µs 18.829µs 0.97% 0.877 3.206 0.18% 0.002µs 1 200
normalization/normalize_name/normalize_name/bad-name throughput 53110688.526op/s 53619600.494op/s ± 94120.429op/s 53626601.158op/s ± 58664.141op/s 53678849.226op/s 53759017.284op/s 53786032.601op/s 53805557.658op/s 0.33% -0.854 3.078 0.18% 6655.319op/s 1 200
normalization/normalize_name/normalize_name/good execution_time 10.810µs 10.886µs ± 0.041µs 10.881µs ± 0.022µs 10.904µs 10.963µs 10.981µs 11.087µs 1.89% 0.978 2.107 0.37% 0.003µs 1 200
normalization/normalize_name/normalize_name/good throughput 90195848.925op/s 91859405.587op/s ± 344051.437op/s 91900706.550op/s ± 183464.024op/s 92082503.815op/s 92368311.572op/s 92453838.792op/s 92507787.249op/s 0.66% -0.943 1.954 0.37% 24328.110op/s 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo... execution_time [205.864µs; 206.009µ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 [4854204.796op/s; 4857597.692op/s] or [-0.035%; +0.035%] None None None
normalization/normalize_name/normalize_name/bad-name execution_time [18.645µs; 18.654µs] or [-0.024%; +0.024%] None None None
normalization/normalize_name/normalize_name/bad-name throughput [53606556.308op/s; 53632644.680op/s] or [-0.024%; +0.024%] None None None
normalization/normalize_name/normalize_name/good execution_time [10.881µs; 10.892µs] or [-0.052%; +0.052%] None None None
normalization/normalize_name/normalize_name/good throughput [91811723.367op/s; 91907087.807op/s] or [-0.052%; +0.052%] None None None

Group 11

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
two way interface execution_time 17.708µs 23.046µs ± 9.033µs 18.106µs ± 0.118µs 27.057µs 43.784µs 44.620µs 63.365µs 249.98% 1.648 1.833 39.10% 0.639µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
two way interface execution_time [21.794µs; 24.298µs] or [-5.432%; +5.432%] None None None

Group 12

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
sdk_test_data/rules-based execution_time 144.460µs 146.234µs ± 1.979µs 145.904µs ± 0.532µs 146.485µs 147.748µs 153.480µs 166.042µs 13.80% 6.453 54.930 1.35% 0.140µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
sdk_test_data/rules-based execution_time [145.959µs; 146.508µs] or [-0.188%; +0.188%] None None None

Group 13

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
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.612µs 85.854µs ± 0.182µs 85.826µs ± 0.068µs 85.916µs 86.032µs 86.279µs 87.656µs 2.13% 5.586 49.072 0.21% 0.013µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
sql/obfuscate_sql_string execution_time [85.829µs; 85.879µs] or [-0.029%; +0.029%] None None None

Group 14

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... execution_time 534.713µs 536.907µs ± 1.299µs 536.573µs ± 0.726µs 537.704µs 539.285µs 540.476µs 542.027µs 1.02% 1.129 1.127 0.24% 0.092µs 1 200
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... throughput 1844925.343op/s 1862529.659op/s ± 4494.047op/s 1863678.905op/s ± 2520.178op/s 1865867.402op/s 1867528.165op/s 1868835.577op/s 1870160.478op/s 0.35% -1.115 1.078 0.24% 317.777op/s 1 200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて execution_time 381.422µs 382.093µs ± 0.383µs 382.040µs ± 0.250µs 382.310µs 382.634µs 383.002µs 384.830µs 0.73% 1.960 11.632 0.10% 0.027µs 1 200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて throughput 2598550.303op/s 2617167.171op/s ± 2615.871op/s 2617524.428op/s ± 1711.296op/s 2619016.881op/s 2620917.929op/s 2621489.354op/s 2621771.303op/s 0.16% -1.931 11.375 0.10% 184.970op/s 1 200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters execution_time 189.557µs 190.053µs ± 0.277µs 190.027µs ± 0.133µs 190.171µs 190.458µs 190.579µs 192.735µs 1.43% 4.699 42.032 0.15% 0.020µs 1 200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters throughput 5188473.236op/s 5261703.829op/s ± 7630.269op/s 5262410.771op/s ± 3675.599op/s 5265942.089op/s 5269922.187op/s 5272336.612op/s 5275451.780op/s 0.25% -4.604 40.817 0.14% 539.541op/s 1 200
normalization/normalize_service/normalize_service/[empty string] execution_time 36.480µs 36.588µs ± 0.052µs 36.586µs ± 0.034µs 36.622µs 36.675µs 36.747µs 36.747µs 0.44% 0.513 0.565 0.14% 0.004µs 1 200
normalization/normalize_service/normalize_service/[empty string] throughput 27212795.424op/s 27331162.765op/s ± 38554.674op/s 27333134.696op/s ± 25099.359op/s 27358080.164op/s 27389671.553op/s 27408004.410op/s 27412537.181op/s 0.29% -0.503 0.547 0.14% 2726.227op/s 1 200
normalization/normalize_service/normalize_service/test_ASCII execution_time 45.899µs 46.050µs ± 0.111µs 46.037µs ± 0.037µs 46.076µs 46.150µs 46.196µs 47.392µs 2.94% 8.914 105.273 0.24% 0.008µs 1 200
normalization/normalize_service/normalize_service/test_ASCII throughput 21100593.335op/s 21715763.954op/s ± 51249.143op/s 21721448.120op/s ± 17339.531op/s 21737044.635op/s 21759565.506op/s 21774435.721op/s 21786808.813op/s 0.30% -8.714 102.066 0.24% 3623.862op/s 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... execution_time [536.727µs; 537.087µs] or [-0.034%; +0.034%] None None None
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... throughput [1861906.827op/s; 1863152.490op/s] or [-0.033%; +0.033%] None None None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて execution_time [382.040µs; 382.146µs] or [-0.014%; +0.014%] None None None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて throughput [2616804.637op/s; 2617529.706op/s] or [-0.014%; +0.014%] None None None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters execution_time [190.014µs; 190.091µs] or [-0.020%; +0.020%] None None None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters throughput [5260646.347op/s; 5262761.311op/s] or [-0.020%; +0.020%] None None None
normalization/normalize_service/normalize_service/[empty string] execution_time [36.581µs; 36.596µs] or [-0.020%; +0.020%] None None None
normalization/normalize_service/normalize_service/[empty string] throughput [27325819.458op/s; 27336506.072op/s] or [-0.020%; +0.020%] None None None
normalization/normalize_service/normalize_service/test_ASCII execution_time [46.034µs; 46.065µs] or [-0.033%; +0.033%] None None None
normalization/normalize_service/normalize_service/test_ASCII throughput [21708661.315op/s; 21722866.592op/s] or [-0.033%; +0.033%] None None None

Group 15

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
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 188.944ns 191.653ns ± 2.233ns 191.213ns ± 1.506ns 192.842ns 195.937ns 198.590ns 200.693ns 4.96% 1.114 1.320 1.16% 0.158ns 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
single_flag_killswitch/rules-based execution_time [191.343ns; 191.962ns] or [-0.161%; +0.161%] None None None

Group 16

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
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.027ms 14.073ms ± 0.028ms 14.069ms ± 0.013ms 14.082ms 14.108ms 14.172ms 14.257ms 1.34% 2.850 13.503 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.069ms; 14.077ms] or [-0.027%; +0.027%] None None None

Group 17

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
receiver_entry_point/report/2597 execution_time 12.682ms 12.993ms ± 0.100ms 13.007ms ± 0.053ms 13.060ms 13.124ms 13.155ms 13.186ms 1.38% -0.854 0.505 0.77% 0.007ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
receiver_entry_point/report/2597 execution_time [12.979ms; 13.007ms] or [-0.107%; +0.107%] None None None

Group 18

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
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.893µs 3.912µs ± 0.003µs 3.912µs ± 0.001µs 3.914µs 3.917µs 3.920µs 3.922µs 0.25% -0.853 11.166 0.07% 0.000µs 1 200
credit_card/is_card_number/ throughput 254965416.575op/s 255593143.485op/s ± 181710.250op/s 255600869.067op/s ± 93282.044op/s 255693756.509op/s 255812443.281op/s 255863302.819op/s 256846114.610op/s 0.49% 0.880 11.330 0.07% 12848.855op/s 1 200
credit_card/is_card_number/ 3782-8224-6310-005 execution_time 77.011µs 77.521µs ± 0.472µs 77.379µs ± 0.256µs 77.725µs 78.442µs 78.890µs 79.805µs 3.14% 1.539 2.887 0.61% 0.033µs 1 200
credit_card/is_card_number/ 3782-8224-6310-005 throughput 12530594.320op/s 12900271.519op/s ± 77909.936op/s 12923465.136op/s ± 42814.604op/s 12961520.237op/s 12972787.458op/s 12977585.778op/s 12985103.067op/s 0.48% -1.494 2.640 0.60% 5509.064op/s 1 200
credit_card/is_card_number/ 378282246310005 execution_time 70.643µs 70.880µs ± 0.315µs 70.745µs ± 0.057µs 70.937µs 71.450µs 72.215µs 72.559µs 2.57% 2.800 8.940 0.44% 0.022µs 1 200
credit_card/is_card_number/ 378282246310005 throughput 13781813.753op/s 14108555.323op/s ± 61926.311op/s 14135325.595op/s ± 11463.500op/s 14142657.437op/s 14151040.610op/s 14154783.727op/s 14155643.002op/s 0.14% -2.759 8.658 0.44% 4378.851op/s 1 200
credit_card/is_card_number/37828224631 execution_time 3.891µs 3.913µs ± 0.003µs 3.913µs ± 0.002µs 3.915µs 3.918µs 3.919µs 3.920µs 0.19% -1.613 10.946 0.08% 0.000µs 1 200
credit_card/is_card_number/37828224631 throughput 255085320.902op/s 255571363.974op/s ± 203567.791op/s 255565802.475op/s ± 128303.106op/s 255695308.014op/s 255860729.153op/s 255924404.499op/s 257013880.659op/s 0.57% 1.638 11.150 0.08% 14394.417op/s 1 200
credit_card/is_card_number/378282246310005 execution_time 67.413µs 67.601µs ± 0.221µs 67.523µs ± 0.050µs 67.606µs 68.032µs 68.436µs 68.853µs 1.97% 2.701 8.852 0.33% 0.016µs 1 200
credit_card/is_card_number/378282246310005 throughput 14523799.453op/s 14792751.587op/s ± 47965.459op/s 14809753.704op/s ± 11053.228op/s 14819180.836op/s 14828877.980op/s 14831476.427op/s 14833890.991op/s 0.16% -2.666 8.591 0.32% 3391.670op/s 1 200
credit_card/is_card_number/37828224631000521389798 execution_time 44.798µs 45.147µs ± 0.150µs 45.153µs ± 0.107µs 45.262µs 45.367µs 45.442µs 45.499µs 0.77% -0.210 -0.570 0.33% 0.011µs 1 200
credit_card/is_card_number/37828224631000521389798 throughput 21978372.292op/s 22150071.697op/s ± 73475.214op/s 22146700.643op/s ± 52452.789op/s 22198661.978op/s 22284457.425op/s 22303321.579op/s 22322290.436op/s 0.79% 0.224 -0.566 0.33% 5195.482op/s 1 200
credit_card/is_card_number/x371413321323331 execution_time 6.027µs 6.035µs ± 0.006µs 6.035µs ± 0.002µs 6.037µs 6.043µs 6.048µs 6.106µs 1.18% 6.671 69.305 0.11% 0.000µs 1 200
credit_card/is_card_number/x371413321323331 throughput 163778970.938op/s 165688339.337op/s ± 175705.613op/s 165703537.771op/s ± 59206.986op/s 165765390.310op/s 165869750.273op/s 165891804.177op/s 165928500.138op/s 0.14% -6.585 68.053 0.11% 12424.263op/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.914µs 3.917µs 3.919µs 3.921µs 0.22% -0.930 7.715 0.07% 0.000µs 1 200
credit_card/is_card_number_no_luhn/ throughput 255014537.625op/s 255586683.739op/s ± 188999.764op/s 255583604.337op/s ± 122679.981op/s 255714214.755op/s 255837815.321op/s 255865579.540op/s 256812050.152op/s 0.48% 0.950 7.843 0.07% 13364.302op/s 1 200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 execution_time 65.493µs 65.791µs ± 0.068µs 65.795µs ± 0.037µs 65.832µs 65.890µs 65.938µs 65.974µs 0.27% -0.663 1.979 0.10% 0.005µs 1 200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 throughput 15157400.127op/s 15199747.200op/s ± 15775.940op/s 15198829.691op/s ± 8613.248op/s 15207144.318op/s 15229099.994op/s 15247954.971op/s 15268706.124op/s 0.46% 0.674 2.006 0.10% 1115.527op/s 1 200
credit_card/is_card_number_no_luhn/ 378282246310005 execution_time 52.945µs 53.011µs ± 0.034µs 53.007µs ± 0.020µs 53.029µs 53.072µs 53.109µs 53.118µs 0.21% 0.801 0.537 0.06% 0.002µs 1 200
credit_card/is_card_number_no_luhn/ 378282246310005 throughput 18826047.520op/s 18864088.484op/s ± 11999.924op/s 18865341.538op/s ± 7213.050op/s 18872419.846op/s 18880271.439op/s 18883197.532op/s 18887655.029op/s 0.12% -0.798 0.529 0.06% 848.523op/s 1 200
credit_card/is_card_number_no_luhn/37828224631 execution_time 3.892µs 3.912µs ± 0.003µs 3.912µs ± 0.002µs 3.914µs 3.916µs 3.919µs 3.928µs 0.41% -0.290 11.253 0.08% 0.000µs 1 200
credit_card/is_card_number_no_luhn/37828224631 throughput 254580330.250op/s 255627951.806op/s ± 198687.894op/s 255627044.049op/s ± 115676.533op/s 255750018.312op/s 255860346.428op/s 255932861.796op/s 256910743.260op/s 0.50% 0.320 11.338 0.08% 14049.356op/s 1 200
credit_card/is_card_number_no_luhn/378282246310005 execution_time 49.734µs 49.820µs ± 0.052µs 49.816µs ± 0.027µs 49.843µs 49.872µs 49.895µs 50.375µs 1.12% 6.026 62.348 0.10% 0.004µs 1 200
credit_card/is_card_number_no_luhn/378282246310005 throughput 19851193.086op/s 20072117.071op/s ± 20848.083op/s 20073715.477op/s ± 10708.313op/s 20084146.078op/s 20094089.628op/s 20099758.608op/s 20106906.722op/s 0.17% -5.939 61.137 0.10% 1474.182op/s 1 200
credit_card/is_card_number_no_luhn/37828224631000521389798 execution_time 44.643µs 45.173µs ± 0.157µs 45.179µs ± 0.102µs 45.281µs 45.408µs 45.523µs 45.592µs 0.91% -0.245 0.429 0.35% 0.011µs 1 200
credit_card/is_card_number_no_luhn/37828224631000521389798 throughput 21933748.421op/s 22137389.452op/s ± 76781.928op/s 22133960.018op/s ± 49952.914op/s 22183640.182op/s 22259904.557op/s 22331403.110op/s 22399914.759op/s 1.20% 0.269 0.459 0.35% 5429.302op/s 1 200
credit_card/is_card_number_no_luhn/x371413321323331 execution_time 6.028µs 6.035µs ± 0.004µs 6.035µs ± 0.002µs 6.038µs 6.042µs 6.047µs 6.048µs 0.23% 0.688 0.308 0.06% 0.000µs 1 200
credit_card/is_card_number_no_luhn/x371413321323331 throughput 165338606.086op/s 165688088.315op/s ± 107854.280op/s 165711824.745op/s ± 64750.588op/s 165764592.683op/s 165848724.697op/s 165875914.443op/s 165894559.899op/s 0.11% -0.684 0.300 0.06% 7626.449op/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 [255567960.192op/s; 255618326.778op/s] or [-0.010%; +0.010%] None None None
credit_card/is_card_number/ 3782-8224-6310-005 execution_time [77.455µs; 77.586µs] or [-0.084%; +0.084%] None None None
credit_card/is_card_number/ 3782-8224-6310-005 throughput [12889473.951op/s; 12911069.087op/s] or [-0.084%; +0.084%] None None None
credit_card/is_card_number/ 378282246310005 execution_time [70.837µs; 70.924µs] or [-0.062%; +0.062%] None None None
credit_card/is_card_number/ 378282246310005 throughput [14099972.932op/s; 14117137.714op/s] or [-0.061%; +0.061%] None None None
credit_card/is_card_number/37828224631 execution_time [3.912µs; 3.913µs] or [-0.011%; +0.011%] None None None
credit_card/is_card_number/37828224631 throughput [255543151.436op/s; 255599576.512op/s] or [-0.011%; +0.011%] None None None
credit_card/is_card_number/378282246310005 execution_time [67.571µs; 67.632µs] or [-0.045%; +0.045%] None None None
credit_card/is_card_number/378282246310005 throughput [14786104.036op/s; 14799399.138op/s] or [-0.045%; +0.045%] None None None
credit_card/is_card_number/37828224631000521389798 execution_time [45.126µs; 45.168µs] or [-0.046%; +0.046%] None None None
credit_card/is_card_number/37828224631000521389798 throughput [22139888.739op/s; 22160254.655op/s] or [-0.046%; +0.046%] None None None
credit_card/is_card_number/x371413321323331 execution_time [6.035µs; 6.036µs] or [-0.015%; +0.015%] None None None
credit_card/is_card_number/x371413321323331 throughput [165663988.229op/s; 165712690.446op/s] or [-0.015%; +0.015%] None None None
credit_card/is_card_number_no_luhn/ execution_time [3.912µs; 3.913µs] or [-0.010%; +0.010%] None None None
credit_card/is_card_number_no_luhn/ throughput [255560490.189op/s; 255612877.289op/s] or [-0.010%; +0.010%] None None None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 execution_time [65.781µs; 65.800µs] or [-0.014%; +0.014%] None None None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 throughput [15197560.806op/s; 15201933.594op/s] or [-0.014%; +0.014%] None None None
credit_card/is_card_number_no_luhn/ 378282246310005 execution_time [53.006µs; 53.015µs] or [-0.009%; +0.009%] None None None
credit_card/is_card_number_no_luhn/ 378282246310005 throughput [18862425.410op/s; 18865751.558op/s] or [-0.009%; +0.009%] None None None
credit_card/is_card_number_no_luhn/37828224631 execution_time [3.912µs; 3.912µs] or [-0.011%; +0.011%] None None None
credit_card/is_card_number_no_luhn/37828224631 throughput [255600415.575op/s; 255655488.037op/s] or [-0.011%; +0.011%] None None None
credit_card/is_card_number_no_luhn/378282246310005 execution_time [49.813µs; 49.828µs] or [-0.014%; +0.014%] None None None
credit_card/is_card_number_no_luhn/378282246310005 throughput [20069227.728op/s; 20075006.415op/s] or [-0.014%; +0.014%] None None None
credit_card/is_card_number_no_luhn/37828224631000521389798 execution_time [45.151µs; 45.195µs] or [-0.048%; +0.048%] None None None
credit_card/is_card_number_no_luhn/37828224631000521389798 throughput [22126748.216op/s; 22148030.689op/s] or [-0.048%; +0.048%] None None None
credit_card/is_card_number_no_luhn/x371413321323331 execution_time [6.035µs; 6.036µs] or [-0.009%; +0.009%] None None None
credit_card/is_card_number_no_luhn/x371413321323331 throughput [165673140.749op/s; 165703035.881op/s] or [-0.009%; +0.009%] None None None

Group 19

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz 7ac277e 1770230202 dsn/fix-headers
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.357µs 2.421µs ± 0.018µs 2.420µs ± 0.006µs 2.430µs 2.447µs 2.460µs 2.495µs 3.08% -0.975 4.728 0.72% 0.001µ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.419µs; 2.423µs] or [-0.101%; +0.101%] None None None

Baseline

Omitted due to size.

@codecov-commenter
Copy link
Copy Markdown

codecov-commenter commented Jan 30, 2026

Codecov Report

❌ Patch coverage is 92.59259% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.25%. Comparing base (7986270) to head (7ac277e).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1493      +/-   ##
==========================================
+ Coverage   71.04%   71.25%   +0.20%     
==========================================
  Files         424      424              
  Lines       69307    69781     +474     
==========================================
+ Hits        49240    49722     +482     
+ Misses      20067    20059       -8     
Components Coverage Δ
libdd-crashtracker 62.37% <ø> (+0.39%) ⬆️
libdd-crashtracker-ffi 16.80% <ø> (+2.68%) ⬆️
libdd-alloc 98.73% <ø> (ø)
libdd-data-pipeline 86.86% <ø> (ø)
libdd-data-pipeline-ffi 78.68% <ø> (ø)
libdd-common 80.58% <95.65%> (+0.05%) ⬆️
libdd-common-ffi 74.54% <ø> (ø)
libdd-telemetry 65.06% <ø> (+5.24%) ⬆️
libdd-telemetry-ffi 21.17% <ø> (ø)
libdd-dogstatsd-client 83.75% <ø> (ø)
datadog-ipc 82.60% <ø> (ø)
libdd-profiling 81.74% <75.00%> (-0.01%) ⬇️
libdd-profiling-ffi 64.71% <ø> (ø)
datadog-sidecar 34.39% <ø> (-0.31%) ⬇️
datdog-sidecar-ffi 7.67% <ø> (-1.48%) ⬇️
spawn-worker 55.18% <ø> (ø)
libdd-tinybytes 93.43% <ø> (ø)
libdd-trace-normalization 82.33% <ø> (ø)
libdd-trace-obfuscation 94.17% <ø> (ø)
libdd-trace-protobuf 61.18% <ø> (ø)
libdd-trace-utils 89.37% <ø> (ø)
datadog-tracer-flare 62.06% <ø> (ø)
libdd-log 75.57% <ø> (ø)
🚀 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.

Copy link
Copy Markdown
Member

@ivoanjo ivoanjo left a comment

Choose a reason for hiding this comment

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

👍 LGTM, Added a note about testing

Comment on lines +10 to +56
pub fn assert_entity_headers_match(headers: &HashMap<String, String>) {
// Check for entity headers and validate their values match what libdd_common provides
let expected_container_id = libdd_common::entity_id::get_container_id();
let expected_entity_id = libdd_common::entity_id::get_entity_id();
let expected_external_env = *libdd_common::entity_id::DD_EXTERNAL_ENV;

// Validate container ID
if let Some(expected) = expected_container_id {
assert_eq!(
headers.get("datadog-container-id"),
Some(&expected.to_string()),
"datadog-container-id header should match the value from entity_id::get_container_id()"
);
} else {
assert!(
!headers.contains_key("datadog-container-id"),
"datadog-container-id header should not be present when entity_id::get_container_id() is None"
);
}

// Validate entity ID
if let Some(expected) = expected_entity_id {
assert_eq!(
headers.get("datadog-entity-id"),
Some(&expected.to_string()),
"datadog-entity-id header should match the value from entity_id::get_entity_id()"
);
} else {
assert!(
!headers.contains_key("datadog-entity-id"),
"datadog-entity-id header should not be present when entity_id::get_entity_id() is None"
);
}

// Validate external env
if let Some(expected) = expected_external_env {
assert_eq!(
headers.get("datadog-external-env"),
Some(&expected.to_string()),
"datadog-external-env header should match the value from entity_id::DD_EXTERNAL_ENV"
);
} else {
assert!(
!headers.contains_key("datadog-external-env"),
"datadog-external-env header should not be present when entity_id::DD_EXTERNAL_ENV is None"
);
}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Hmmm I'm not the biggest fan of these tests, since they change their behavior dynamically based on the exact execution environment of the test runner, which means that

a) Whatever I get running on my machine may be different -- so maybe it fails in CI but never for me
b) We don't get full test coverage -- only whatever codepaths end up being picked

Is it possible to maybe mock the results of those functions for our tests?

That is, what I would do if this were Ruby would be to zoom out and say "the behavior in my headers is -- if each of these entries is available, the headers contain what got returned, and if there was nothing than the headers don't exist"

Then I'd mock container-id: [dummy-container-id, none], entity-id: [dummy-entity-id, none], external-env: [dummy-external-env, none] and check that I get the correct behavior in each of the 6 cases.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Rust doesn't have great capabilities for mocking. I'm going to merge this, then post a followup PR with the mocking code since its somewhat intrusive and we can discuss the benefits there.

Copy link
Copy Markdown
Contributor

@morrisonlevi morrisonlevi Feb 3, 2026

Choose a reason for hiding this comment

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

It looks a bit like the underlying code, e.g. get_entity_id and such were not written in such a way to be testable. Maybe we should re-examine that angle in the follow-up PR, rather than mocking specifically? It looks like get_entity_id specifically might not be too hard based on looking at the source code.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Agree that improving the test separately isn't a blocker. I would in any case leave a big comment above assert_entity_headers_match explaining the situation until we fix it?

Comment on lines +10 to +56
pub fn assert_entity_headers_match(headers: &HashMap<String, String>) {
// Check for entity headers and validate their values match what libdd_common provides
let expected_container_id = libdd_common::entity_id::get_container_id();
let expected_entity_id = libdd_common::entity_id::get_entity_id();
let expected_external_env = *libdd_common::entity_id::DD_EXTERNAL_ENV;

// Validate container ID
if let Some(expected) = expected_container_id {
assert_eq!(
headers.get("datadog-container-id"),
Some(&expected.to_string()),
"datadog-container-id header should match the value from entity_id::get_container_id()"
);
} else {
assert!(
!headers.contains_key("datadog-container-id"),
"datadog-container-id header should not be present when entity_id::get_container_id() is None"
);
}

// Validate entity ID
if let Some(expected) = expected_entity_id {
assert_eq!(
headers.get("datadog-entity-id"),
Some(&expected.to_string()),
"datadog-entity-id header should match the value from entity_id::get_entity_id()"
);
} else {
assert!(
!headers.contains_key("datadog-entity-id"),
"datadog-entity-id header should not be present when entity_id::get_entity_id() is None"
);
}

// Validate external env
if let Some(expected) = expected_external_env {
assert_eq!(
headers.get("datadog-external-env"),
Some(&expected.to_string()),
"datadog-external-env header should match the value from entity_id::DD_EXTERNAL_ENV"
);
} else {
assert!(
!headers.contains_key("datadog-external-env"),
"datadog-external-env header should not be present when entity_id::DD_EXTERNAL_ENV is None"
);
}
Copy link
Copy Markdown
Contributor

@morrisonlevi morrisonlevi Feb 3, 2026

Choose a reason for hiding this comment

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

It looks a bit like the underlying code, e.g. get_entity_id and such were not written in such a way to be testable. Maybe we should re-examine that angle in the follow-up PR, rather than mocking specifically? It looks like get_entity_id specifically might not be too hard based on looking at the source code.

Co-authored-by: Levi Morrison <[email protected]>
@danielsn danielsn changed the title fix(profiling): missing headers in exporter fix(profiling)!: missing headers in exporter Feb 3, 2026
@danielsn danielsn changed the title fix(profiling)!: missing headers in exporter fix(profiling): missing headers in exporter Feb 3, 2026
@dd-octo-sts
Copy link
Copy Markdown
Contributor

dd-octo-sts bot commented Feb 4, 2026

Artifact Size Benchmark Report

aarch64-alpine-linux-musl
Artifact Baseline Commit Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 8.38 MB 8.38 MB 0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 91.65 MB 91.66 MB +0% (+4.67 KB) 👌
aarch64-apple-darwin
Artifact Baseline Commit Change
/aarch64-apple-darwin/lib/libdatadog_profiling.a 62.64 MB 62.65 MB +.01% (+9.05 KB) 🔍
/aarch64-apple-darwin/lib/libdatadog_profiling.dylib 9.46 MB 9.46 MB +0% (+352 B) 👌
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 106.36 MB 106.37 MB +.01% (+12.19 KB) 🔍
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 10.76 MB 10.76 MB +0% (+368 B) 👌
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 25.05 MB 25.06 MB +0% (+2.50 KB) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 75.94 KB 75.94 KB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 172.43 MB 172.47 MB +.02% (+40.00 KB) 🔍
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 882.36 MB 882.43 MB +0% (+69.90 KB) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 9.56 MB 9.56 MB -0% (-512 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 75.94 KB 75.94 KB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 23.04 MB 23.04 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 48.23 MB 48.23 MB +0% (+868 B) 👌
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 21.19 MB 21.20 MB +0% (+1.50 KB) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 77.12 KB 77.12 KB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 176.51 MB 176.56 MB +.03% (+56.00 KB) 🔍
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 868.51 MB 868.57 MB +0% (+64.58 KB) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 7.24 MB 7.23 MB --.01% (-1.00 KB) 💪
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 77.12 KB 77.12 KB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 24.62 MB 24.62 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 43.92 MB 43.93 MB +0% (+1.92 KB) 👌
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 80.15 MB 80.16 MB +0% (+4.35 KB) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 9.86 MB 9.86 MB 0% (0 B) 👌
x86_64-apple-darwin
Artifact Baseline Commit Change
/x86_64-apple-darwin/lib/libdatadog_profiling.a 64.86 MB 64.87 MB +.01% (+9.16 KB) 🔍
/x86_64-apple-darwin/lib/libdatadog_profiling.dylib 10.47 MB 10.47 MB +0% (+352 B) 👌
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 100.27 MB 100.28 MB +0% (+8.11 KB) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.44 MB 11.44 MB +0% (+392 B) 👌

@danielsn danielsn changed the title fix(profiling): missing headers in exporter feat: single source of truth for headers (fixes issue in profiling with missing headers) Feb 4, 2026
@danielsn
Copy link
Copy Markdown
Contributor Author

danielsn commented Feb 4, 2026

/merge

@gh-worker-devflow-routing-ef8351
Copy link
Copy Markdown

gh-worker-devflow-routing-ef8351 bot commented Feb 4, 2026

View all feedbacks in Devflow UI.

2026-02-04 18:54:34 UTC ℹ️ Start processing command /merge


2026-02-04 18:54:41 UTC ℹ️ MergeQueue: waiting for PR to be ready

This pull request is not mergeable according to GitHub. Common reasons include pending required checks, missing approvals, or merge conflicts — but it could also be blocked by other repository rules or settings.
It will be added to the queue as soon as checks pass and/or get approvals. View in MergeQueue UI.
Note: if you pushed new commits since the last approval, you may need additional approval.
You can remove it from the waiting list with /remove command.


2026-02-04 19:05:44 UTC ℹ️ MergeQueue: merge request added to the queue

The expected merge time in main is approximately 33m (p90).


2026-02-04 19:33:27 UTC ℹ️ MergeQueue: This merge request was merged

iunanua pushed a commit that referenced this pull request Feb 9, 2026
# Release proposal for libdd-common and its dependencies

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

## libdd-common
**Next version:** `1.2.0`

**Semver bump:** `minor`
**Tag:** `libdd-common-v1.2.0`

### Commits

- feat: single source of truth for headers (fixes issue in profiling
with missing headers) (#1493)
- refactor!: make reqwest available in common (#1504)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
iunanua pushed a commit that referenced this pull request Feb 10, 2026
# Release proposal for libdd-common and its dependencies

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

## libdd-common
**Next version:** `1.2.0`

**Semver bump:** `minor`
**Tag:** `libdd-common-v1.2.0`

### Commits

- feat: single source of truth for headers (fixes issue in profiling
with missing headers) (#1493)
- refactor!: make reqwest available in common (#1504)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
iunanua pushed a commit that referenced this pull request Feb 10, 2026
# Release proposal for libdd-common and its dependencies

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

## libdd-common
**Next version:** `1.2.0`

**Semver bump:** `minor`
**Tag:** `libdd-common-v1.2.0`

### Commits

- feat: single source of truth for headers (fixes issue in profiling
with missing headers) (#1493)
- refactor!: make reqwest available in common (#1504)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
paullegranddc pushed a commit that referenced this pull request Feb 23, 2026
# Release proposal for libdd-data-pipeline and its dependencies

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

## libdd-common
**Next version:** `2.0.0`

**Semver bump:** `major`
**Tag:** `libdd-common-v2.0.0`

### Commits

- refactor(ddcommon)!: remove direct dependency on hyper client
everywhere in common (#1604)
- feat!: enable non-blocking DNS for reqwest (#1558)
- feat: unify Azure tags (#1553)
- feat(common): add current thread id API (#1569)
- refactor!: switch from multipart to multer to resolve deprecation
warnings and dependabot alerts (#1540)
- feat: single source of truth for headers (fixes issue in profiling
with missing headers) (#1493)
- refactor!: make reqwest available in common (#1504)
## libdd-ddsketch
**Next version:** `1.0.1`

**Semver bump:** `patch`
**Tag:** `libdd-ddsketch-v1.0.1`

### Commits

- chore: remove manual changelog modifications (#1472)
- build: update `prost` crates (#1426)
- chore: add changelog for every published crate (#1396)
## libdd-trace-protobuf
**Next version:** `1.1.0`

**Semver bump:** `minor`
**Tag:** `libdd-trace-protobuf-v1.1.0`

### Commits

- chore: remove manual changelog modifications (#1472)
- build: update `prost` crates (#1426)
- chore: add changelog for every published crate (#1396)
- Handle null span tag values (#1394)
## libdd-dogstatsd-client
**Next version:** `1.0.1`

**Semver bump:** `patch`
**Tag:** `libdd-dogstatsd-client-v1.0.1`

### Commits

- refactor(ddcommon)!: remove direct dependency on hyper client
everywhere in common (#1604)
- chore: release libddcommon-v1.1.0 (#1456)
- chore: add changelog for every published crate (#1396)
- style: fix recent clippy warnings (#1346)
## libdd-telemetry
**Next version:** `3.0.0`

**Semver bump:** `major`
**Tag:** `libdd-telemetry-v3.0.0`

### Commits

- refactor(ddcommon)!: remove direct dependency on hyper client
everywhere in common (#1604)
- chore(deps): bump tracing-subscriber to remove regex dep duplicate
(#1608)
- feat(telemetry)!: add process_tags to Application in telemetry (#1459)
- fix(telemetry)!: fix logs payload format [APMSP-2590] (#1498)
- feat(appsec): add endpoints collection (#1182)
## libdd-trace-normalization
**Next version:** `1.0.1`

**Semver bump:** `patch`
**Tag:** `libdd-trace-normalization-v1.0.1`

### Commits

- Prevent span start overflow panic (#1373)
- [CHAOSPLT-932] Add support for internal fuzzing infra  (#1372)
- chore: add changelog for every published crate (#1396)
## libdd-trace-utils
**Next version:** `2.0.0`

**Semver bump:** `major`
**Tag:** `libdd-trace-utils-v2.0.0`

### Commits

- refactor(ddcommon)!: remove direct dependency on hyper client
everywhere in common (#1604)
- feat: unify Azure tags (#1553)
- fix(serverless): set hostname on stats from tracer to empty string
(#1530)
- chore: remove manual changelog modifications (#1472)
- feat(sidecar)!: introduce TraceData to unify text and binary data
(#1247)
- chore: release libddcommon-v1.1.0 (#1456)
- fix(test-agent): undo commenting arg in docker cmd (#1439)
- [SLES-2652] Log error details when trace request fails (2) (#1441)
- build: update `prost` crates (#1426)
- chore(trace-utils): bump the test agent version used for integration
tests (#1417)
- [Serverless] Skip AAS metadata tagging when span is from API
Management (#1409)
- chore: add changelog for every published crate (#1396)
- Handle null span tag values (#1394)
- [SVLS-7934] Log error details when trace request fails (#1392)
- Fix trace utils clippy warning (#1397)
- feat(trace_utils): Allow sending trace stats using custom HTTP client
(#1345)
## libdd-trace-stats
**Next version:** `1.0.1`

**Semver bump:** `patch`
**Tag:** `libdd-trace-stats-v1.0.1`

### Commits

- feat(sidecar)!: introduce TraceData to unify text and binary data
(#1247)
- chore: add changelog for every published crate (#1396)
## libdd-data-pipeline
**Next version:** `2.0.0`

**Semver bump:** `major`
**Tag:** `libdd-data-pipeline-v2.0.0`

### Commits

- refactor(ddcommon)!: remove direct dependency on hyper client
everywhere in common (#1604)
- refactor(trace_exporter)!: remove Proxy TraceExporter input mode
(#1583)
- refactor(libdd-data-pipeline): health metrics (#1433)
- feat(data-pipeline)!: include reason for chunks dropped telemetry
(#1449)
- feat(sidecar)!: introduce TraceData to unify text and binary data
(#1247)
- chore: release libddcommon-v1.1.0 (#1456)
- chore: prepare libdd-telemetry-v2.0.0 (#1457)
- Allow submitting Vec<Vec<Span>> asynchronously (#1302)
- test(data-pipeline): handle EINTR in test_health_metrics_disabled
(#1430)
- chore: add changelog for every published crate (#1396)

[APMSP-2590]:
https://datadoghq.atlassian.net/browse/APMSP-2590?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

---------

Co-authored-by: dd-octo-sts[bot] <200755185+dd-octo-sts[bot]@users.noreply.github.com>
dd-octo-sts bot added a commit that referenced this pull request Feb 25, 2026
# Release proposal for libdd-data-pipeline and its dependencies

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

## libdd-common
**Next version:** `2.0.0`

**Semver bump:** `major`
**Tag:** `libdd-common-v2.0.0`

### Commits

- refactor(ddcommon)!: remove direct dependency on hyper client
everywhere in common (#1604)
- feat!: enable non-blocking DNS for reqwest (#1558)
- feat: unify Azure tags (#1553)
- feat(common): add current thread id API (#1569)
- refactor!: switch from multipart to multer to resolve deprecation
warnings and dependabot alerts (#1540)
- feat: single source of truth for headers (fixes issue in profiling
with missing headers) (#1493)
- refactor!: make reqwest available in common (#1504)
## libdd-ddsketch
**Next version:** `1.0.1`

**Semver bump:** `patch`
**Tag:** `libdd-ddsketch-v1.0.1`

### Commits

- chore: remove manual changelog modifications (#1472)
- build: update `prost` crates (#1426)
- chore: add changelog for every published crate (#1396)
## libdd-trace-protobuf
**Next version:** `1.1.0`

**Semver bump:** `minor`
**Tag:** `libdd-trace-protobuf-v1.1.0`

### Commits

- chore: remove manual changelog modifications (#1472)
- build: update `prost` crates (#1426)
- chore: add changelog for every published crate (#1396)
- Handle null span tag values (#1394)
## libdd-dogstatsd-client
**Next version:** `1.0.1`

**Semver bump:** `patch`
**Tag:** `libdd-dogstatsd-client-v1.0.1`

### Commits

- refactor(ddcommon)!: remove direct dependency on hyper client
everywhere in common (#1604)
- chore: release libddcommon-v1.1.0 (#1456)
- chore: add changelog for every published crate (#1396)
- style: fix recent clippy warnings (#1346)
## libdd-telemetry
**Next version:** `3.0.0`

**Semver bump:** `major`
**Tag:** `libdd-telemetry-v3.0.0`

### Commits

- refactor(ddcommon)!: remove direct dependency on hyper client
everywhere in common (#1604)
- chore(deps): bump tracing-subscriber to remove regex dep duplicate
(#1608)
- feat(telemetry)!: add process_tags to Application in telemetry (#1459)
- fix(telemetry)!: fix logs payload format [APMSP-2590] (#1498)
- feat(appsec): add endpoints collection (#1182)
## libdd-trace-normalization
**Next version:** `1.0.1`

**Semver bump:** `patch`
**Tag:** `libdd-trace-normalization-v1.0.1`

### Commits

- Prevent span start overflow panic (#1373)
- [CHAOSPLT-932] Add support for internal fuzzing infra  (#1372)
- chore: add changelog for every published crate (#1396)
## libdd-trace-utils
**Next version:** `2.0.0`

**Semver bump:** `major`
**Tag:** `libdd-trace-utils-v2.0.0`

### Commits

- refactor(ddcommon)!: remove direct dependency on hyper client
everywhere in common (#1604)
- feat: unify Azure tags (#1553)
- fix(serverless): set hostname on stats from tracer to empty string
(#1530)
- chore: remove manual changelog modifications (#1472)
- feat(sidecar)!: introduce TraceData to unify text and binary data
(#1247)
- chore: release libddcommon-v1.1.0 (#1456)
- fix(test-agent): undo commenting arg in docker cmd (#1439)
- [SLES-2652] Log error details when trace request fails (2) (#1441)
- build: update `prost` crates (#1426)
- chore(trace-utils): bump the test agent version used for integration
tests (#1417)
- [Serverless] Skip AAS metadata tagging when span is from API
Management (#1409)
- chore: add changelog for every published crate (#1396)
- Handle null span tag values (#1394)
- [SVLS-7934] Log error details when trace request fails (#1392)
- Fix trace utils clippy warning (#1397)
- feat(trace_utils): Allow sending trace stats using custom HTTP client
(#1345)
## libdd-trace-stats
**Next version:** `1.0.1`

**Semver bump:** `patch`
**Tag:** `libdd-trace-stats-v1.0.1`

### Commits

- feat(sidecar)!: introduce TraceData to unify text and binary data
(#1247)
- chore: add changelog for every published crate (#1396)
## libdd-data-pipeline
**Next version:** `2.0.0`

**Semver bump:** `major`
**Tag:** `libdd-data-pipeline-v2.0.0`

### Commits

- refactor(ddcommon)!: remove direct dependency on hyper client
everywhere in common (#1604)
- refactor(trace_exporter)!: remove Proxy TraceExporter input mode
(#1583)
- refactor(libdd-data-pipeline): health metrics (#1433)
- feat(data-pipeline)!: include reason for chunks dropped telemetry
(#1449)
- feat(sidecar)!: introduce TraceData to unify text and binary data
(#1247)
- chore: release libddcommon-v1.1.0 (#1456)
- chore: prepare libdd-telemetry-v2.0.0 (#1457)
- Allow submitting Vec<Vec<Span>> asynchronously (#1302)
- test(data-pipeline): handle EINTR in test_health_metrics_disabled
(#1430)
- chore: add changelog for every published crate (#1396)

[APMSP-2590]:
https://datadoghq.atlassian.net/browse/APMSP-2590?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

---------

Co-authored-by: dd-octo-sts[bot] <200755185+dd-octo-sts[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants