Skip to content

refactor!: make reqwest available in common#1504

Merged
gh-worker-dd-mergequeue-cf854d[bot] merged 4 commits intomainfrom
dsn/common-reqwest
Feb 3, 2026
Merged

refactor!: make reqwest available in common#1504
gh-worker-dd-mergequeue-cf854d[bot] merged 4 commits intomainfrom
dsn/common-reqwest

Conversation

@danielsn
Copy link
Copy Markdown
Contributor

@danielsn danielsn commented Feb 3, 2026

What does this PR do?

Enables anyone using common to use reqwest

Motivation

Reqwest is nicer than hyper, and the code to use it was in profiling but not profiling specific.

Additional Notes

I put this under a feature flag to limit impact to those who use it.

How to test the change?

New tests added.

@github-actions github-actions bot added the common label Feb 3, 2026
@github-actions
Copy link
Copy Markdown

github-actions bot commented Feb 3, 2026 •
edited
Loading

📚 Documentation Check Results

⚠️ 747 documentation warning(s) found

📦 libdd-common - 155 warning(s)

📦 libdd-profiling - 592 warning(s)

Updated: 2026-02-03 22:12:16 UTC | Commit: c0f1240 | missing-docs job results

@github-actions
Copy link
Copy Markdown

github-actions bot commented Feb 3, 2026 •
edited
Loading

🔒 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-03 22:14:55 UTC | Commit: c0f1240 | dependency-check job results

@danielsn danielsn marked this pull request as ready for review February 3, 2026 18:14
@danielsn danielsn requested review from a team as code owners February 3, 2026 18:14
taegyunkim
taegyunkim approved these changes Feb 3, 2026
View reviewed changes
Copy link
Copy Markdown
Contributor

@taegyunkim taegyunkim left a comment

Choose a reason for hiding this comment

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

Mostly lgtm, some non blocking questions

@pr-commenter
Copy link
Copy Markdown

pr-commenter bot commented Feb 3, 2026 •
edited
Loading

Benchmarks

Comparison

Benchmark execution time: 2026-02-03 21:07:06

Comparing candidate commit aef72ec in PR branch dsn/common-reqwest with baseline commit 46ab1d6 in branch main.

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

scenario:benching serializing traces from their internal representation to msgpack

  • 🟩 execution_time [-601.172µs; -588.831µs] or [-4.105%; -4.020%]

scenario:sql/obfuscate_sql_string

  • 🟩 execution_time [-4.958µs; -4.890µs] or [-5.537%; -5.461%]

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 aef72ec 1770151840 dsn/common-reqwest
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.348µs 2.399µs ± 0.017µs 2.397µs ± 0.006µs 2.404µs 2.436µs 2.446µs 2.522µs 5.21% 2.446 14.649 0.70% 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.397µs; 2.402µs] or [-0.097%; +0.097%] None None None

Group 2

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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.624ms 12.994ms ± 0.072ms 13.001ms ± 0.033ms 13.037ms 13.083ms 13.104ms 13.112ms 0.86% -2.111 6.789 0.55% 0.005ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
receiver_entry_point/report/2597 execution_time [12.984ms; 13.004ms] or [-0.077%; +0.077%] None None None

Group 3

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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.688µs 34.213µs ± 0.774µs 33.864µs ± 0.109µs 34.067µs 35.799µs 35.828µs 37.566µs 10.93% 1.759 1.808 2.26% 0.055µ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.106µs; 34.320µs] or [-0.313%; +0.313%] None None None

Group 4

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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.713µs 206.530µs ± 0.432µs 206.467µs ± 0.282µs 206.782µs 207.402µs 207.619µs 207.690µs 0.59% 0.532 -0.096 0.21% 0.031µs 1 200
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo... throughput 4814859.541op/s 4841922.581op/s ± 10119.992op/s 4843389.651op/s ± 6620.591op/s 4849603.634op/s 4857395.149op/s 4860575.840op/s 4861142.132op/s 0.37% -0.521 -0.109 0.21% 715.592op/s 1 200
normalization/normalize_name/normalize_name/bad-name execution_time 18.608µs 18.687µs ± 0.067µs 18.665µs ± 0.030µs 18.704µs 18.841µs 18.924µs 18.953µs 1.54% 1.722 2.959 0.36% 0.005µs 1 200
normalization/normalize_name/normalize_name/bad-name throughput 52761576.695op/s 53514701.818op/s ± 191858.456op/s 53575969.016op/s ± 86500.021op/s 53648190.632op/s 53701201.735op/s 53718127.028op/s 53739078.557op/s 0.30% -1.700 2.867 0.36% 13566.442op/s 1 200
normalization/normalize_name/normalize_name/good execution_time 10.726µs 10.813µs ± 0.032µs 10.811µs ± 0.020µs 10.831µs 10.856µs 10.915µs 10.956µs 1.35% 0.915 3.374 0.30% 0.002µs 1 200
normalization/normalize_name/normalize_name/good throughput 91272852.179op/s 92486247.981op/s ± 273784.222op/s 92501777.669op/s ± 169203.010op/s 92659379.008op/s 92909409.328op/s 93009019.572op/s 93229940.618op/s 0.79% -0.875 3.234 0.30% 19359.468op/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 [206.471µs; 206.590µs] or [-0.029%; +0.029%] None None None
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo... throughput [4840520.047op/s; 4843325.115op/s] or [-0.029%; +0.029%] None None None
normalization/normalize_name/normalize_name/bad-name execution_time [18.677µs; 18.696µs] or [-0.050%; +0.050%] None None None
normalization/normalize_name/normalize_name/bad-name throughput [53488112.081op/s; 53541291.554op/s] or [-0.050%; +0.050%] None None None
normalization/normalize_name/normalize_name/good execution_time [10.808µs; 10.817µs] or [-0.041%; +0.041%] None None None
normalization/normalize_name/normalize_name/good throughput [92448304.121op/s; 92524191.841op/s] or [-0.041%; +0.041%] None None None

Group 5

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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.619ms 10.648ms ± 0.016ms 10.645ms ± 0.011ms 10.658ms 10.677ms 10.690ms 10.710ms 0.61% 0.675 0.505 0.15% 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.646ms; 10.650ms] or [-0.021%; +0.021%] None None None

Group 6

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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.389µs 146.027µs ± 1.665µs 145.715µs ± 0.522µs 146.302µs 147.953µs 152.220µs 162.083µs 11.23% 5.743 46.521 1.14% 0.118µ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.796µs; 146.257µs] or [-0.158%; +0.158%] None None None

Group 7

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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.980µs 5.048µs ± 0.045µs 5.031µs ± 0.025µs 5.086µs 5.123µs 5.126µs 5.131µs 1.99% 0.585 -1.178 0.90% 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.042µs; 5.054µs] or [-0.125%; +0.125%] None None None

Group 8

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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.163µs 3.186µs ± 1.422µs 2.980µs ± 0.028µs 3.007µs 3.653µs 13.764µs 14.806µs 396.89% 7.380 55.544 44.51% 0.101µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
write only interface execution_time [2.989µs; 3.383µs] or [-6.185%; +6.185%] None None None

Group 9

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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.100µs 161.932µs ± 0.397µs 161.839µs ± 0.131µs 162.034µs 162.575µs 163.014µs 165.472µs 2.24% 4.136 30.764 0.24% 0.028µ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.877µs; 161.987µs] or [-0.034%; +0.034%] None None None

Group 10

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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.878µs 25.145µs ± 9.287µs 18.146µs ± 0.181µs 33.985µs 43.177µs 43.867µs 66.930µs 268.85% 1.064 0.810 36.84% 0.657µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
two way interface execution_time [23.858µs; 26.432µs] or [-5.119%; +5.119%] None None None

Group 11

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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.892µs 3.912µs ± 0.003µs 3.912µs ± 0.002µs 3.914µs 3.917µs 3.918µs 3.923µs 0.28% -1.265 11.625 0.07% 0.000µs 1 200
credit_card/is_card_number/ throughput 254893486.235op/s 255594410.590op/s ± 186930.335op/s 255604345.274op/s ± 110115.650op/s 255708324.439op/s 255814313.587op/s 255917501.748op/s 256915329.412op/s 0.51% 1.291 11.810 0.07% 13217.971op/s 1 200
credit_card/is_card_number/ 3782-8224-6310-005 execution_time 77.059µs 77.476µs ± 0.373µs 77.405µs ± 0.253µs 77.660µs 78.250µs 78.533µs 78.589µs 1.53% 1.107 0.526 0.48% 0.026µs 1 200
credit_card/is_card_number/ 3782-8224-6310-005 throughput 12724395.946op/s 12907537.320op/s ± 61825.881op/s 12919021.639op/s ± 42270.299op/s 12960461.856op/s 12970251.043op/s 12973296.001op/s 12977088.949op/s 0.45% -1.088 0.473 0.48% 4371.750op/s 1 200
credit_card/is_card_number/ 378282246310005 execution_time 70.618µs 70.862µs ± 0.364µs 70.732µs ± 0.049µs 70.916µs 71.408µs 72.215µs 74.160µs 4.85% 4.918 35.018 0.51% 0.026µs 1 200
credit_card/is_card_number/ 378282246310005 throughput 13484354.276op/s 14112217.639op/s ± 70647.853op/s 14137875.368op/s ± 9754.041op/s 14144576.988op/s 14153825.584op/s 14157875.541op/s 14160726.861op/s 0.16% -4.730 32.460 0.50% 4995.558op/s 1 200
credit_card/is_card_number/37828224631 execution_time 3.891µs 3.912µs ± 0.003µs 3.911µs ± 0.001µs 3.913µs 3.916µs 3.920µs 3.921µs 0.23% -1.653 17.210 0.07% 0.000µs 1 200
credit_card/is_card_number/37828224631 throughput 255060181.535op/s 255646835.768op/s ± 178629.967op/s 255657139.081op/s ± 95827.359op/s 255750101.447op/s 255834702.087op/s 255889718.484op/s 257030389.295op/s 0.54% 1.687 17.485 0.07% 12631.046op/s 1 200
credit_card/is_card_number/378282246310005 execution_time 67.434µs 67.659µs ± 0.323µs 67.518µs ± 0.039µs 67.726µs 68.460µs 68.967µs 69.052µs 2.27% 2.476 6.030 0.48% 0.023µs 1 200
credit_card/is_card_number/378282246310005 throughput 14481750.499op/s 14780247.685op/s ± 69737.245op/s 14810945.289op/s ± 8501.405op/s 14817348.893op/s 14823345.286op/s 14826674.730op/s 14829272.985op/s 0.12% -2.450 5.871 0.47% 4931.168op/s 1 200
credit_card/is_card_number/37828224631000521389798 execution_time 44.756µs 45.100µs ± 0.117µs 45.105µs ± 0.073µs 45.173µs 45.287µs 45.350µs 45.385µs 0.62% -0.184 0.084 0.26% 0.008µs 1 200
credit_card/is_card_number/37828224631000521389798 throughput 22033847.165op/s 22172854.000op/s ± 57656.168op/s 22170368.196op/s ± 36146.085op/s 22207603.885op/s 22277651.686op/s 22317317.272op/s 22343570.849op/s 0.78% 0.200 0.096 0.26% 4076.907op/s 1 200
credit_card/is_card_number/x371413321323331 execution_time 6.028µs 6.037µs ± 0.012µs 6.035µs ± 0.003µs 6.038µs 6.044µs 6.105µs 6.109µs 1.23% 5.007 26.650 0.19% 0.001µs 1 200
credit_card/is_card_number/x371413321323331 throughput 163698458.943op/s 165650611.683op/s ± 319242.620op/s 165712677.020op/s ± 93165.140op/s 165785760.991op/s 165849048.544op/s 165887354.007op/s 165900739.895op/s 0.11% -4.986 26.490 0.19% 22573.862op/s 1 200
credit_card/is_card_number_no_luhn/ execution_time 3.892µs 3.912µs ± 0.003µs 3.912µs ± 0.002µs 3.913µs 3.916µs 3.920µs 3.920µs 0.22% -1.111 12.085 0.07% 0.000µs 1 200
credit_card/is_card_number_no_luhn/ throughput 255095907.382op/s 255641275.590op/s ± 178876.001op/s 255655835.469op/s ± 102989.066op/s 255757455.913op/s 255831849.346op/s 255893099.236op/s 256915183.125op/s 0.49% 1.138 12.277 0.07% 12648.443op/s 1 200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 execution_time 65.503µs 65.769µs ± 0.077µs 65.776µs ± 0.052µs 65.820µs 65.879µs 65.931µs 65.990µs 0.32% -0.329 0.430 0.12% 0.005µs 1 200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 throughput 15153833.845op/s 15204654.913op/s ± 17795.570op/s 15203057.336op/s ± 12072.591op/s 15217070.900op/s 15237322.527op/s 15248855.764op/s 15266484.011op/s 0.42% 0.337 0.438 0.12% 1258.337op/s 1 200
credit_card/is_card_number_no_luhn/ 378282246310005 execution_time 52.951µs 53.024µs ± 0.037µs 53.024µs ± 0.026µs 53.048µs 53.081µs 53.129µs 53.160µs 0.26% 0.491 0.601 0.07% 0.003µs 1 200
credit_card/is_card_number_no_luhn/ 378282246310005 throughput 18811169.894op/s 18859438.843op/s ± 13047.476op/s 18859529.339op/s ± 9095.335op/s 18869453.657op/s 18878947.520op/s 18883289.837op/s 18885326.102op/s 0.14% -0.486 0.588 0.07% 922.596op/s 1 200
credit_card/is_card_number_no_luhn/37828224631 execution_time 3.897µs 3.912µs ± 0.003µs 3.912µs ± 0.002µs 3.914µs 3.916µs 3.917µs 3.920µs 0.21% -0.700 4.809 0.06% 0.000µs 1 200
credit_card/is_card_number_no_luhn/37828224631 throughput 255084506.594op/s 255608682.477op/s ± 165151.748op/s 255623083.035op/s ± 118151.558op/s 255727382.022op/s 255823589.660op/s 255890033.492op/s 256579863.668op/s 0.37% 0.712 4.878 0.06% 11677.992op/s 1 200
credit_card/is_card_number_no_luhn/378282246310005 execution_time 49.745µs 49.792µs ± 0.026µs 49.788µs ± 0.015µs 49.806µs 49.842µs 49.861µs 49.877µs 0.18% 0.797 0.465 0.05% 0.002µs 1 200
credit_card/is_card_number_no_luhn/378282246310005 throughput 20049131.344op/s 20083472.641op/s ± 10458.763op/s 20085240.361op/s ± 6029.982op/s 20090946.517op/s 20097923.382op/s 20100873.846op/s 20102372.080op/s 0.09% -0.794 0.458 0.05% 739.546op/s 1 200
credit_card/is_card_number_no_luhn/37828224631000521389798 execution_time 44.719µs 45.187µs ± 0.152µs 45.197µs ± 0.117µs 45.303µs 45.414µs 45.460µs 45.491µs 0.65% -0.267 -0.425 0.34% 0.011µs 1 200
credit_card/is_card_number_no_luhn/37828224631000521389798 throughput 21982470.267op/s 22130471.254op/s ± 74683.473op/s 22125482.571op/s ± 57281.029op/s 22184260.268op/s 22256409.876op/s 22290598.358op/s 22361875.380op/s 1.07% 0.282 -0.405 0.34% 5280.919op/s 1 200
credit_card/is_card_number_no_luhn/x371413321323331 execution_time 6.027µs 6.038µs ± 0.017µs 6.034µs ± 0.003µs 6.037µs 6.054µs 6.106µs 6.157µs 2.03% 4.307 19.981 0.27% 0.001µs 1 200
credit_card/is_card_number_no_luhn/x371413321323331 throughput 162427667.245op/s 165619169.313op/s ± 449889.740op/s 165730005.418op/s ± 68881.532op/s 165785835.617op/s 165854188.835op/s 165885715.861op/s 165909145.068op/s 0.11% -4.279 19.664 0.27% 31812.009op/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 [255568503.843op/s; 255620317.337op/s] or [-0.010%; +0.010%] None None None
credit_card/is_card_number/ 3782-8224-6310-005 execution_time [77.424µs; 77.528µs] or [-0.067%; +0.067%] None None None
credit_card/is_card_number/ 3782-8224-6310-005 throughput [12898968.847op/s; 12916105.792op/s] or [-0.066%; +0.066%] None None None
credit_card/is_card_number/ 378282246310005 execution_time [70.812µs; 70.913µs] or [-0.071%; +0.071%] None None None
credit_card/is_card_number/ 378282246310005 throughput [14102426.526op/s; 14122008.752op/s] or [-0.069%; +0.069%] None None None
credit_card/is_card_number/37828224631 execution_time [3.911µs; 3.912µs] or [-0.010%; +0.010%] None None None
credit_card/is_card_number/37828224631 throughput [255622079.372op/s; 255671592.163op/s] or [-0.010%; +0.010%] None None None
credit_card/is_card_number/378282246310005 execution_time [67.615µs; 67.704µs] or [-0.066%; +0.066%] None None None
credit_card/is_card_number/378282246310005 throughput [14770582.773op/s; 14789912.597op/s] or [-0.065%; +0.065%] None None None
credit_card/is_card_number/37828224631000521389798 execution_time [45.084µs; 45.117µs] or [-0.036%; +0.036%] None None None
credit_card/is_card_number/37828224631000521389798 throughput [22164863.410op/s; 22180844.590op/s] or [-0.036%; +0.036%] None None None
credit_card/is_card_number/x371413321323331 execution_time [6.035µs; 6.038µs] or [-0.027%; +0.027%] None None None
credit_card/is_card_number/x371413321323331 throughput [165606367.726op/s; 165694855.640op/s] or [-0.027%; +0.027%] None None None
credit_card/is_card_number_no_luhn/ execution_time [3.911µs; 3.912µs] or [-0.010%; +0.010%] None None None
credit_card/is_card_number_no_luhn/ throughput [255616485.096op/s; 255666066.083op/s] or [-0.010%; +0.010%] None None None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 execution_time [65.759µs; 65.780µs] or [-0.016%; +0.016%] None None None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 throughput [15202188.619op/s; 15207121.208op/s] or [-0.016%; +0.016%] None None None
credit_card/is_card_number_no_luhn/ 378282246310005 execution_time [53.019µs; 53.029µs] or [-0.010%; +0.010%] None None None
credit_card/is_card_number_no_luhn/ 378282246310005 throughput [18857630.588op/s; 18861247.098op/s] or [-0.010%; +0.010%] None None None
credit_card/is_card_number_no_luhn/37828224631 execution_time [3.912µs; 3.913µs] or [-0.009%; +0.009%] None None None
credit_card/is_card_number_no_luhn/37828224631 throughput [255585794.033op/s; 255631570.921op/s] or [-0.009%; +0.009%] None None None
credit_card/is_card_number_no_luhn/378282246310005 execution_time [49.789µs; 49.796µs] or [-0.007%; +0.007%] None None None
credit_card/is_card_number_no_luhn/378282246310005 throughput [20082023.157op/s; 20084922.125op/s] or [-0.007%; +0.007%] None None None
credit_card/is_card_number_no_luhn/37828224631000521389798 execution_time [45.166µs; 45.208µs] or [-0.047%; +0.047%] None None None
credit_card/is_card_number_no_luhn/37828224631000521389798 throughput [22120120.843op/s; 22140821.665op/s] or [-0.047%; +0.047%] None None None
credit_card/is_card_number_no_luhn/x371413321323331 execution_time [6.036µs; 6.040µs] or [-0.038%; +0.038%] None None None
credit_card/is_card_number_no_luhn/x371413321323331 throughput [165556818.922op/s; 165681519.705op/s] or [-0.038%; +0.038%] None None None

Group 12

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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 13.998ms 14.051ms ± 0.031ms 14.046ms ± 0.013ms 14.060ms 14.093ms 14.167ms 14.235ms 1.34% 2.751 11.375 0.22% 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.047ms; 14.056ms] or [-0.031%; +0.031%] None None None

Group 13

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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.043ms 48.350ms ± 1.083ms 48.206ms ± 0.073ms 48.278ms 48.466ms 54.233ms 58.483ms 21.32% 8.275 69.376 2.24% 0.077ms 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.200ms; 48.500ms] or [-0.311%; +0.311%] None None None

Group 14

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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 241.701ns 254.039ns ± 13.659ns 247.340ns ± 3.646ns 259.601ns 285.380ns 289.007ns 290.576ns 17.48% 1.324 0.440 5.36% 0.966ns 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.146ns; 255.932ns] or [-0.745%; +0.745%] None None None

Group 15

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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.965ms 3.969ms ± 0.007ms 3.968ms ± 0.001ms 3.970ms 3.972ms 3.975ms 4.059ms 2.29% 11.793 153.390 0.17% 0.000ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profile_add_sample_frames_x1000 execution_time [3.968ms; 3.970ms] or [-0.024%; +0.024%] None None None

Group 16

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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 543.367µs 543.929µs ± 0.349µs 543.869µs ± 0.178µs 544.082µs 544.511µs 545.006µs 546.475µs 0.48% 2.662 14.223 0.06% 0.025µ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 [543.881µs; 543.977µs] or [-0.009%; +0.009%] None None None

Group 17

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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 84.337µs 84.609µs ± 0.190µs 84.590µs ± 0.075µs 84.667µs 84.813µs 85.011µs 86.704µs 2.50% 6.824 71.591 0.22% 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 [84.583µs; 84.636µs] or [-0.031%; +0.031%] None None None

Group 18

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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.851µs 536.924µs ± 1.507µs 536.274µs ± 0.696µs 537.780µs 539.927µs 541.593µs 543.067µs 1.27% 1.332 1.686 0.28% 0.107µs 1 200
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... throughput 1841393.419op/s 1862476.204op/s ± 5209.027op/s 1864717.898op/s ± 2423.359op/s 1866199.379op/s 1867835.293op/s 1869161.129op/s 1869679.593op/s 0.27% -1.316 1.619 0.28% 368.334op/s 1 200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて execution_time 381.583µs 382.187µs ± 0.323µs 382.138µs ± 0.193µs 382.338µs 382.826µs 383.021µs 383.178µs 0.27% 0.760 0.388 0.08% 0.023µs 1 200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて throughput 2609751.393op/s 2616521.083op/s ± 2211.317op/s 2616857.775op/s ± 1318.215op/s 2618133.231op/s 2619592.633op/s 2620346.735op/s 2620664.211op/s 0.15% -0.755 0.380 0.08% 156.364op/s 1 200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters execution_time 189.610µs 190.109µs ± 0.200µs 190.086µs ± 0.146µs 190.255µs 190.445µs 190.552µs 190.751µs 0.35% 0.287 -0.290 0.10% 0.014µs 1 200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters throughput 5242433.039op/s 5260150.407op/s ± 5533.193op/s 5260763.209op/s ± 4036.472op/s 5264260.619op/s 5268783.049op/s 5270243.043op/s 5273993.175op/s 0.25% -0.282 -0.295 0.10% 391.256op/s 1 200
normalization/normalize_service/normalize_service/[empty string] execution_time 36.466µs 36.611µs ± 0.054µs 36.606µs ± 0.034µs 36.643µs 36.697µs 36.763µs 36.764µs 0.43% 0.332 0.324 0.15% 0.004µs 1 200
normalization/normalize_service/normalize_service/[empty string] throughput 27200755.663op/s 27314357.080op/s ± 40097.866op/s 27317766.112op/s ± 25447.616op/s 27341455.975op/s 27372291.558op/s 27408423.415op/s 27422437.757op/s 0.38% -0.322 0.316 0.15% 2835.347op/s 1 200
normalization/normalize_service/normalize_service/test_ASCII execution_time 45.908µs 46.042µs ± 0.056µs 46.038µs ± 0.036µs 46.072µs 46.142µs 46.203µs 46.232µs 0.42% 0.712 0.846 0.12% 0.004µs 1 200
normalization/normalize_service/normalize_service/test_ASCII throughput 21630194.094op/s 21719501.267op/s ± 26521.539op/s 21721239.548op/s ± 16772.048op/s 21738319.776op/s 21756329.714op/s 21771963.402op/s 21782721.065op/s 0.28% -0.703 0.830 0.12% 1875.356op/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.715µs; 537.133µs] or [-0.039%; +0.039%] None None None
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... throughput [1861754.283op/s; 1863198.125op/s] or [-0.039%; +0.039%] None None None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて execution_time [382.142µs; 382.232µs] or [-0.012%; +0.012%] None None None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて throughput [2616214.616op/s; 2616827.550op/s] or [-0.012%; +0.012%] None None None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters execution_time [190.081µs; 190.137µs] or [-0.015%; +0.015%] None None None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters throughput [5259383.560op/s; 5260917.254op/s] or [-0.015%; +0.015%] None None None
normalization/normalize_service/normalize_service/[empty string] execution_time [36.603µs; 36.618µs] or [-0.020%; +0.020%] None None None
normalization/normalize_service/normalize_service/[empty string] throughput [27308799.901op/s; 27319914.259op/s] or [-0.020%; +0.020%] None None None
normalization/normalize_service/normalize_service/test_ASCII execution_time [46.034µs; 46.049µs] or [-0.017%; +0.017%] None None None
normalization/normalize_service/normalize_service/test_ASCII throughput [21715825.637op/s; 21723176.897op/s] or [-0.017%; +0.017%] None None None

Group 19

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz aef72ec 1770151840 dsn/common-reqwest
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.756ns 191.066ns ± 1.818ns 191.038ns ± 1.590ns 192.280ns 194.545ns 195.695ns 196.196ns 2.70% 0.663 -0.314 0.95% 0.129ns 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 [190.814ns; 191.318ns] or [-0.132%; +0.132%] None None None

Baseline

Omitted due to size.

@codecov-commenter
Copy link
Copy Markdown

codecov-commenter commented Feb 3, 2026 •
edited
Loading

Codecov Report

❌ Patch coverage is 89.21569% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.06%. Comparing base (46ab1d6) to head (3a1703f).

Additional details and impacted files 
@@            Coverage Diff             @@
##             main    #1504      +/-   ##
==========================================
- Coverage   71.10%   71.06%   -0.04%     
==========================================
  Files         424      424              
  Lines       69216    69307      +91     
==========================================
+ Hits        49214    49256      +42     
- Misses      20002    20051      +49
Components Coverage Δ
libdd-crashtracker 61.96% <ø> (-0.28%) ⬇️
libdd-crashtracker-ffi 14.11% <ø> (-2.11%) ⬇️
libdd-alloc 98.73% <ø> (ø)
libdd-data-pipeline 86.86% <ø> (+0.01%) ⬆️
libdd-data-pipeline-ffi 78.68% <ø> (+0.10%) ⬆️
libdd-common 80.53% <89.10%> (-0.45%) ⬇️
libdd-common-ffi 74.54% <100.00%> (ø)
libdd-telemetry 59.82% <ø> (ø)
libdd-telemetry-ffi 21.17% <ø> (ø)
libdd-dogstatsd-client 83.75% <ø> (ø)
datadog-ipc 82.70% <ø> (ø)
libdd-profiling 81.73% <100.00%> (+0.23%) ⬆️
libdd-profiling-ffi 64.71% <ø> (ø)
datadog-sidecar 34.70% <ø> (-0.25%) ⬇️
datdog-sidecar-ffi 9.15% <ø> (-1.11%) ⬇️
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% <ø> (-0.08%) ⬇️
datadog-tracer-flare 62.06% <ø> (-1.43%) ⬇️
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.

@danielsn danielsn changed the title refactor: make reqwest available in common refactor!: make reqwest available in common Feb 3, 2026
@danielsn
Copy link
Copy Markdown
Contributor Author

danielsn commented Feb 3, 2026

/merge

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

gh-worker-devflow-routing-ef8351 bot commented Feb 3, 2026 •
edited
Loading

View all feedbacks in Devflow UI.

2026-02-03 21:38:08 UTC ℹ️ Start processing command /merge

2026-02-03 21:38:15 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-03 22:10:31 UTC ℹ️ MergeQueue: merge request added to the queue

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

2026-02-03 22:38:09 UTC ℹ️ MergeQueue: This merge request was merged

@gh-worker-dd-mergequeue-cf854d gh-worker-dd-mergequeue-cf854d bot merged commit 7986270 into main Feb 3, 2026
71 checks passed
@gh-worker-dd-mergequeue-cf854d gh-worker-dd-mergequeue-cf854d bot deleted the dsn/common-reqwest branch February 3, 2026 22:38
@dd-octo-sts dd-octo-sts bot mentioned this pull request Feb 9, 2026
Merged
iunanua pushed a commit that referenced this pull request Feb 9, 2026
@dd-octo-sts @github-actions
chore(release): proposal for libdd-common (#1536)
4d13520 
# 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>
@dd-octo-sts dd-octo-sts bot mentioned this pull request Feb 9, 2026
Closed
@dd-octo-sts dd-octo-sts bot mentioned this pull request Feb 10, 2026
Merged
iunanua pushed a commit that referenced this pull request Feb 10, 2026
@dd-octo-sts @github-actions
chore(release): proposal for libdd-common (#1542)
41347cd 
# 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>
@dd-octo-sts dd-octo-sts bot mentioned this pull request Feb 10, 2026
Merged
iunanua pushed a commit that referenced this pull request Feb 10, 2026
@dd-octo-sts @github-actions
chore(release): proposal for libdd-common (#1543)
cebb83e 
# 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>
This was referenced Feb 13, 2026
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
@atlassian atlassian bot mentioned this pull request Feb 18, 2026
Closed
This was referenced Feb 18, 2026
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Merged
paullegranddc pushed a commit that referenced this pull request Feb 23, 2026
@dd-octo-sts
chore(release): proposal for libdd-data-pipeline (#1623)
47eb5f8 
# 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
@dd-octo-sts
chore(release): proposal for libdd-data-pipeline (#1623)
144f58b 
# 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

Reviewers

@taegyunkim taegyunkim taegyunkim approved these changes

Assignees

No one assigned

Labels

common mergequeue-status: done

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@danielsn @codecov-commenter @taegyunkim