ci: update nightly in CI to 2026-02-08

[ekump]

What does this PR do?

Updating Rust nightly toolchain on CI to a current version.

Motivation

Our nightly is over a year old

Additional Notes

Anything else we should know when reviewing?

How to test the change?

Describe here in detail how the change can be validated.

[github-actions]

📚 Documentation Check Results

⚠️ 1033 documentation warning(s) found

📦 libdd-crashtracker - 997 warning(s)

📦 libdd-library-config - 36 warning(s)

---

Updated: 2026-02-10 05:03:26 UTC | Commit: 4166e81 | missing-docs job results

[github-actions]

🔒 Cargo Deny Results

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

📦 libdd-crashtracker - 7 error(s)

Show output

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

error[vulnerability]: Lenient `hyper` header parsing of `Content-Length` could allow request smuggling
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:93:1
   │
93 │ hyper 0.10.16 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2021-0078
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2021-0078
   ├ `hyper`'s HTTP header parser accepted, according to RFC 7230, illegal contents inside `Content-Length` headers.
     Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error.
     
     To be vulnerable, `hyper` must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents
     but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.
   ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-f3pg-qwvg-p99c
   ├ Solution: Upgrade to >=0.14.10 (try `cargo update -p hyper`)
   ├ hyper v0.10.16
     ├── iron v0.6.1
     │   └── multipart v0.18.0
     │       └── (dev) libdd-common v1.1.0
     │           ├── (build) libdd-crashtracker v1.0.0
     │           └── libdd-telemetry v2.0.0
     │               └── libdd-crashtracker 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:93:1
   │
93 │ hyper 0.10.16 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2021-0079
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2021-0079
   ├ When decoding chunk sizes that are too large, `hyper`'s code would encounter an integer overflow. Depending on the situation,
     this could lead to data loss from an incorrect total size, or in rarer cases, a request smuggling attack.
     
     To be vulnerable, you must be using `hyper` for any HTTP/1 purpose, including as a client or server, and consumers must send
     requests or responses that specify a chunk size greater than 18 exabytes. For a possible request smuggling attack to be possible,
     any upstream proxies must accept a chunk size greater than 64 bits.
   ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-5h46-h7hh-c6x9
   ├ Solution: Upgrade to >=0.14.10 (try `cargo update -p hyper`)
   ├ hyper v0.10.16
     ├── iron v0.6.1
     │   └── multipart v0.18.0
     │       └── (dev) libdd-common v1.1.0
     │           ├── (build) libdd-crashtracker v1.0.0
     │           └── libdd-telemetry v2.0.0
     │               └── libdd-crashtracker 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:99:1
   │
99 │ idna 0.1.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2024-0421
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0421
   ├ `idna` 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with `idna` 0.5.0 or earlier.
     
     Concretely, `example.org` and `xn--example-.org` become equal after processing by `idna` 0.5.0 or earlier. Also, `example.org.xn--` and `example.org.` become equal after processing by `idna` 0.5.0 or earlier.
     
     In applications using `idna` (but not in `idna` itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an `xn--`-masked name that turns into the name of the target when processed by `idna` 0.5.0 or earlier.
     
     ## Remedy
     
     Upgrade to `idna` 1.0.3 or later, if depending on `idna` directly, or to `url` 2.5.4 or later, if depending on `idna` via `url`. (This issue was fixed in `idna` 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)
     
     When upgrading, please take a moment to read about [alternative Unicode back ends for `idna`](https://docs.rs/crate/idna_adapter/latest).
     
     If you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an [issue](https://github.com/servo/rust-url/issues/992) about combining them with `url` 2.5.4 and `idna` 1.0.3.
     
     ## Additional information
     
     This issue resulted from `idna` 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in [revision 33 of UTS 46](https://www.unicode.org/reports/tr46/tr46-33.html#Modifications).
     
     ## Acknowledgements
     
     Thanks to kageshiron for recognizing the security implications of this behavior.
   ├ Announcement: https://bugzilla.mozilla.org/show_bug.cgi?id=1887898
   ├ Solution: Upgrade to >=1.0.0 (try `cargo update -p idna`)
   ├ idna v0.1.5
     └── url v1.7.2
         ├── hyper v0.10.16
         │   ├── iron v0.6.1
         │   │   └── multipart v0.18.0
         │   │       └── (dev) libdd-common v1.1.0
         │   │           ├── (build) libdd-crashtracker v1.0.0
         │   │           └── libdd-telemetry v2.0.0
         │   │               └── libdd-crashtracker 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:135:1
    │
135 │ multipart 0.18.0 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
    │
    ├ ID: RUSTSEC-2023-0050
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2023-0050
    ├ The `multipart` crate is unmaintained. The author has archived the github
      repository.
      
      Alternatives:
      
      - [multer](https://crates.io/crates/multer)
      - [multiparty](https://crates.io/crates/multiparty)
    ├ Solution: No safe upgrade is available!
    ├ multipart v0.18.0
      └── (dev) libdd-common v1.1.0
          ├── (build) libdd-crashtracker v1.0.0
          └── libdd-telemetry v2.0.0
              └── libdd-crashtracker v1.0.0 (*)

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

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

advisories FAILED, bans ok, sources ok

📦 libdd-library-config - ✅ No issues

---

Updated: 2026-02-10 05:06:11 UTC | Commit: 4166e81 | dependency-check job results

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.91%. Comparing base (e0df0d6) to head (419e9a9).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1539      +/-   ##
==========================================
- Coverage   71.78%   70.91%   -0.87%     
==========================================
  Files         426      423       -3     
  Lines       70114    61680    -8434     
==========================================
- Hits        50334    43743    -6591     
+ Misses      19780    17937    -1843     

Components	Coverage Δ
libdd-crashtracker	62.32% <ø> (-0.06%)	⬇️
libdd-crashtracker-ffi	15.80% <ø> (-1.00%)	⬇️
libdd-alloc	98.77% <ø> (+0.04%)	⬆️
libdd-data-pipeline	85.68% <ø> (-1.18%)	⬇️
libdd-data-pipeline-ffi	74.66% <ø> (-4.02%)	⬇️
libdd-common	79.82% <ø> (-0.77%)	⬇️
libdd-common-ffi	73.75% <ø> (-0.80%)	⬇️
libdd-telemetry	62.52% <ø> (-2.58%)	⬇️
libdd-telemetry-ffi	16.75% <ø> (-4.43%)	⬇️
libdd-dogstatsd-client	82.64% <ø> (-1.11%)	⬇️
datadog-ipc	80.71% <ø> (-1.89%)	⬇️
libdd-profiling	81.52% <ø> (-0.32%)	⬇️
libdd-profiling-ffi	63.56% <ø> (-1.18%)	⬇️
datadog-sidecar	33.61% <ø> (-1.66%)	⬇️
datdog-sidecar-ffi	12.16% <ø> (+0.50%)	⬆️
spawn-worker	54.69% <ø> (-0.50%)	⬇️
libdd-tinybytes	93.16% <ø> (-0.28%)	⬇️
libdd-trace-normalization	81.71% <ø> (-0.63%)	⬇️
libdd-trace-obfuscation	94.18% <ø> (+0.01%)	⬆️
libdd-trace-protobuf	68.00% <ø> (+6.81%)	⬆️
libdd-trace-utils	88.58% <ø> (-0.79%)	⬇️
datadog-tracer-flare	90.10% <ø> (-5.23%)	⬇️
libdd-log	74.69% <ø> (-0.89%)	⬇️

🚀 New features to boost your workflow:

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

[dd-octo-sts]

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

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

aarch64-unknown-linux-gnu

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

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	25.08 MB	25.08 MB	0% (0 B) 👌
/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.52 MB	172.52 MB	0% (0 B) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	882.83 MB	882.80 MB	-0% (-27.57 KB) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	9.57 MB	9.57 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	75.94 KB	75.94 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	23.04 MB	23.04 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	48.45 MB	48.45 MB	-0% (-44 B) 👌

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	21.22 MB	21.22 MB	0% (0 B) 👌
/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.62 MB	176.63 MB	+0% (+8.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	866.92 MB	866.89 MB	-0% (-27.42 KB) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	7.24 MB	7.24 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	77.12 KB	77.12 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	24.62 MB	24.62 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	44.15 MB	44.15 MB	-0% (-48 B) 👌

x86_64-alpine-linux-musl

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

x86_64-unknown-linux-gnu

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

[ekump]

this is only used in tests that have the same gate to not run on our alpine builds at the moment and I was getting unused import warnings.

[ekump]

this is only called by tests that have the same cfg targets. It should resolve dead code warnings on other envs.

[ekump]

moved the import since it's only used for linux with this function. It should resolve unused import warnings in other envs.

[morrisonlevi]

What are these CFGs for, in relation to updating nightly? New warnings or..?

[morrisonlevi]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-02-10 05:01:54 UTC ℹ️ Start processing command /merge

---

2026-02-10 05:01:58 UTC ℹ️ MergeQueue: pull request added to the queue

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

---

2026-02-10 05:41:05 UTC ℹ️ MergeQueue: This merge request was merged