You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today SharedRuntime::block_on is buried deep inside the data pipeline (in check_agent_info, stop_stats_computation, telemetry start-up and send_deser).
That forces every internal path to block on a runtime even when the caller is
already async, and makes it impossible for an async host to drive libdatadog
without nested-runtime hazards.
This PR pushes the async/sync boundary up to the top-level public entry
points. The internals are now async all the way down, and the synchronous
methods are thin block_on facades over their _async counterparts. This is a
prerequisite for letting async consumers (e.g. a Rust service embedding dd-trace-rs) call the _async API directly.
The change is self-contained to libdd-data-pipeline and does not touch libdd-shared-runtime; the sync facades keep using the existing owned-mode SharedRuntime::block_on.
What changed
trace_exporter/mod.rs
send, send_trace_chunks, shutdown are now thin block_on facades over send_async, send_trace_chunks_async and the new shutdown_async.
check_agent_info is now async (native + wasm); it awaits the stats path
and takes an owned status snapshot via load_full() to avoid holding a !SendArcSwap guard across .await.
Removed send_deser — its deserialize-and-send logic already lives in send_async.
trace_exporter/builder.rs
Added build_async (the real builder body); build is now a block_on
facade that materializes the SharedRuntime up front so both share a single
instance.
Telemetry start-up is awaited directly (client_tel.start().await) instead of block_on.
The !SendHandle::enter() guard is scoped to a block so it drops before any .await, keeping the future Send.
trace_exporter/stats.rs
stop_stats_computation and handle_stats_enabled are now async and await
the stats-worker shutdown directly instead of routing through block_on.
Notes / compatibility
Public sync signatures (send, send_trace_chunks, shutdown, build) are
unchanged, so FFI callers are unaffected.
The sync build facade is gated to native (#[cfg(not(target_arch = "wasm32"))]),
matching the existing convention where send/send_trace_chunks are
native-only and wasm consumers use the _async variants (block_on does not
exist on wasm). build_async is cross-platform.
This report tracks Clippy allow annotations for specific rules, showing how they've changed in this PR. Decreasing the number of these annotations generally improves code quality.
⚠️5 issue(s) found, showing only errors (advisories, bans, sources)
📦 libdd-data-pipeline - 5 error(s)
Show output
error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:214:1
│
214 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
│
├ ID: RUSTSEC-2026-0097
├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
- The `log` and `thread_rng` features are enabled
- A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
- The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
- The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
- Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
`TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
├ Announcement: https://github.com/rust-random/rand/pull/1763
├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
├ rand v0.8.5
├── libdd-common v4.1.0
│ ├── libdd-capabilities-impl v2.0.0
│ │ ├── libdd-data-pipeline v5.0.0
│ │ ├── libdd-shared-runtime v1.0.0
│ │ │ ├── libdd-data-pipeline v5.0.0 (*)
│ │ │ ├── libdd-telemetry v5.0.0
│ │ │ │ └── libdd-data-pipeline v5.0.0 (*)
│ │ │ └── libdd-trace-stats v4.0.0
│ │ │ └── libdd-data-pipeline v5.0.0 (*)
│ │ ├── libdd-trace-stats v4.0.0 (*)
│ │ └── libdd-trace-utils v5.0.0
│ │ ├── libdd-data-pipeline v5.0.0 (*)
│ │ ├── libdd-trace-obfuscation v3.1.0
│ │ │ └── libdd-trace-stats v4.0.0 (*)
│ │ ├── libdd-trace-stats v4.0.0 (*)
│ │ └── (dev) libdd-trace-utils v5.0.0 (*)
│ ├── libdd-data-pipeline v5.0.0 (*)
│ ├── libdd-dogstatsd-client v3.0.0
│ │ └── libdd-data-pipeline v5.0.0 (*)
│ ├── libdd-shared-runtime v1.0.0 (*)
│ ├── libdd-telemetry v5.0.0 (*)
│ ├── libdd-trace-obfuscation v3.1.0 (*)
│ ├── libdd-trace-stats v4.0.0 (*)
│ └── libdd-trace-utils v5.0.0 (*)
├── (dev) libdd-data-pipeline v5.0.0 (*)
├── (dev) libdd-trace-normalization v2.0.0
│ └── libdd-trace-utils v5.0.0 (*)
├── (dev) libdd-trace-stats v4.0.0 (*)
├── libdd-trace-utils v5.0.0 (*)
└── proptest v1.5.0
└── (dev) libdd-tinybytes v1.1.1
├── libdd-data-pipeline v5.0.0 (*)
├── (dev) libdd-tinybytes v1.1.1 (*)
└── libdd-trace-utils v5.0.0 (*)
error[vulnerability]: Name constraints for URI names were incorrectly accepted
┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:238:1
│
238 │ rustls-webpki 0.103.10 registry+https://github.com/rust-lang/crates.io-index
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
│
├ ID: RUSTSEC-2026-0098
├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0098
├ Name constraints for URI names were ignored and therefore accepted.
Note this library does not provide an API for asserting URI names, and URI name constraints are otherwise not implemented. URI name constraints are now rejected unconditionally.
Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.
This vulnerability is identified as [GHSA-965h-392x-2mh5](https://github.com/rustls/webpki/security/advisories/GHSA-965h-392x-2mh5). Thank you to @1seal for the report.
├ Solution: Upgrade to >=0.103.12, <0.104.0-alpha.1 OR >=0.104.0-alpha.6 (try `cargo update -p rustls-webpki`)
├ rustls-webpki v0.103.10
└── rustls v0.23.37
├── hyper-rustls v0.27.7
│ └── libdd-common v4.1.0
│ ├── libdd-capabilities-impl v2.0.0
│ │ ├── libdd-data-pipeline v5.0.0
│ │ ├── libdd-shared-runtime v1.0.0
│ │ │ ├── libdd-data-pipeline v5.0.0 (*)
│ │ │ ├── libdd-telemetry v5.0.0
│ │ │ │ └── libdd-data-pipeline v5.0.0 (*)
│ │ │ └── libdd-trace-stats v4.0.0
│ │ │ └── libdd-data-pipeline v5.0.0 (*)
│ │ ├── libdd-trace-stats v4.0.0 (*)
│ │ └── libdd-trace-utils v5.0.0
│ │ ├── libdd-data-pipeline v5.0.0 (*)
│ │ ├── libdd-trace-obfuscation v3.1.0
│ │ │ └── libdd-trace-stats v4.0.0 (*)
│ │ ├── libdd-trace-stats v4.0.0 (*)
│ │ └── (dev) libdd-trace-utils v5.0.0 (*)
│ ├── libdd-data-pipeline v5.0.0 (*)
│ ├── libdd-dogstatsd-client v3.0.0
│ │ └── libdd-data-pipeline v5.0.0 (*)
│ ├── libdd-shared-runtime v1.0.0 (*)
│ ├── libdd-telemetry v5.0.0 (*)
│ ├── libdd-trace-obfuscation v3.1.0 (*)
│ ├── libdd-trace-stats v4.0.0 (*)
│ └── libdd-trace-utils v5.0.0 (*)
├── libdd-common v4.1.0 (*)
└── tokio-rustls v0.26.0
├── hyper-rustls v0.27.7 (*)
└── libdd-common v4.1.0 (*)
error[vulnerability]: Name constraints were accepted for certificates asserting a wildcard name
┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:238:1
│
238 │ rustls-webpki 0.103.10 registry+https://github.com/rust-lang/crates.io-index
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
│
├ ID: RUSTSEC-2026-0099
├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0099
├ Permitted subtree name constraints for DNS names were accepted for certificates asserting a wildcard name.
This was incorrect because, given a name constraint of `accept.example.com`, `*.example.com` could feasibly allow a name of `reject.example.com` which is outside the constraint.
This is very similar to [CVE-2025-61727](https://go.dev/issue/76442).
Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.
This vulnerability is identified as [GHSA-xgp8-3hg3-c2mh](https://github.com/rustls/webpki/security/advisories/GHSA-xgp8-3hg3-c2mh). Thank you to @1seal for the report.
├ Solution: Upgrade to >=0.103.12, <0.104.0-alpha.1 OR >=0.104.0-alpha.6 (try `cargo update -p rustls-webpki`)
├ rustls-webpki v0.103.10
└── rustls v0.23.37
├── hyper-rustls v0.27.7
│ └── libdd-common v4.1.0
│ ├── libdd-capabilities-impl v2.0.0
│ │ ├── libdd-data-pipeline v5.0.0
│ │ ├── libdd-shared-runtime v1.0.0
│ │ │ ├── libdd-data-pipeline v5.0.0 (*)
│ │ │ ├── libdd-telemetry v5.0.0
│ │ │ │ └── libdd-data-pipeline v5.0.0 (*)
│ │ │ └── libdd-trace-stats v4.0.0
│ │ │ └── libdd-data-pipeline v5.0.0 (*)
│ │ ├── libdd-trace-stats v4.0.0 (*)
│ │ └── libdd-trace-utils v5.0.0
│ │ ├── libdd-data-pipeline v5.0.0 (*)
│ │ ├── libdd-trace-obfuscation v3.1.0
│ │ │ └── libdd-trace-stats v4.0.0 (*)
│ │ ├── libdd-trace-stats v4.0.0 (*)
│ │ └── (dev) libdd-trace-utils v5.0.0 (*)
│ ├── libdd-data-pipeline v5.0.0 (*)
│ ├── libdd-dogstatsd-client v3.0.0
│ │ └── libdd-data-pipeline v5.0.0 (*)
│ ├── libdd-shared-runtime v1.0.0 (*)
│ ├── libdd-telemetry v5.0.0 (*)
│ ├── libdd-trace-obfuscation v3.1.0 (*)
│ ├── libdd-trace-stats v4.0.0 (*)
│ └── libdd-trace-utils v5.0.0 (*)
├── libdd-common v4.1.0 (*)
└── tokio-rustls v0.26.0
├── hyper-rustls v0.27.7 (*)
└── libdd-common v4.1.0 (*)
error[vulnerability]: Reachable panic in certificate revocation list parsing
┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:238:1
│
238 │ rustls-webpki 0.103.10 registry+https://github.com/rust-lang/crates.io-index
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
│
├ ID: RUSTSEC-2026-0104
├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0104
├ A panic was reachable when parsing certificate revocation lists via [`BorrowedCertRevocationList::from_der`]
or [`OwnedCertRevocationList::from_der`]. This was the result of mishandling a syntactically valid empty
`BIT STRING` appearing in the `onlySomeReasons` element of a `IssuingDistributionPoint` CRL extension.
This panic is reachable prior to a CRL's signature being verified.
Applications that do not use CRLs are not affected.
Thank you to @tynus3 for the report.
├ Solution: Upgrade to >=0.103.13, <0.104.0-alpha.1 OR >=0.104.0-alpha.7 (try `cargo update -p rustls-webpki`)
├ rustls-webpki v0.103.10
└── rustls v0.23.37
├── hyper-rustls v0.27.7
│ └── libdd-common v4.1.0
│ ├── libdd-capabilities-impl v2.0.0
│ │ ├── libdd-data-pipeline v5.0.0
│ │ ├── libdd-shared-runtime v1.0.0
│ │ │ ├── libdd-data-pipeline v5.0.0 (*)
│ │ │ ├── libdd-telemetry v5.0.0
│ │ │ │ └── libdd-data-pipeline v5.0.0 (*)
│ │ │ └── libdd-trace-stats v4.0.0
│ │ │ └── libdd-data-pipeline v5.0.0 (*)
│ │ ├── libdd-trace-stats v4.0.0 (*)
│ │ └── libdd-trace-utils v5.0.0
│ │ ├── libdd-data-pipeline v5.0.0 (*)
│ │ ├── libdd-trace-obfuscation v3.1.0
│ │ │ └── libdd-trace-stats v4.0.0 (*)
│ │ ├── libdd-trace-stats v4.0.0 (*)
│ │ └── (dev) libdd-trace-utils v5.0.0 (*)
│ ├── libdd-data-pipeline v5.0.0 (*)
│ ├── libdd-dogstatsd-client v3.0.0
│ │ └── libdd-data-pipeline v5.0.0 (*)
│ ├── libdd-shared-runtime v1.0.0 (*)
│ ├── libdd-telemetry v5.0.0 (*)
│ ├── libdd-trace-obfuscation v3.1.0 (*)
│ ├── libdd-trace-stats v4.0.0 (*)
│ └── libdd-trace-utils v5.0.0 (*)
├── libdd-common v4.1.0 (*)
└── tokio-rustls v0.26.0
├── hyper-rustls v0.27.7 (*)
└── libdd-common v4.1.0 (*)
error[vulnerability]: Denial of Service via Stack Exhaustion
┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:278:1
│
278 │ time 0.3.41 registry+https://github.com/rust-lang/crates.io-index
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
│
├ ID: RUSTSEC-2026-0009
├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
├ ## Impact
When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
service attack via stack exhaustion is possible. The attack relies on formally deprecated and
rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
non-malicious input will never encounter this scenario.
## Patches
A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
rather than exhausting the stack.
## Workarounds
Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
the stack consumed would be at most a factor of the length of the input.
├ Announcement: https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05
├ Solution: Upgrade to >=0.3.47 (try `cargo update -p time`)
├ time v0.3.41
└── tracing-appender v0.2.3
└── libdd-log v1.0.0
└── (dev) libdd-data-pipeline v5.0.0
advisories FAILED, bans ok, sources ok
❌ Patch coverage is 68.42105% with 24 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.97%. Comparing base (b603b76) to head (a8618b2).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Today
SharedRuntime::block_onis buried deep inside the data pipeline (incheck_agent_info,stop_stats_computation, telemetry start-up andsend_deser).That forces every internal path to block on a runtime even when the caller is
already async, and makes it impossible for an async host to drive libdatadog
without nested-runtime hazards.
This PR pushes the async/sync boundary up to the top-level public entry
points. The internals are now async all the way down, and the synchronous
methods are thin
block_onfacades over their_asynccounterparts. This is aprerequisite for letting async consumers (e.g. a Rust service embedding
dd-trace-rs) call the_asyncAPI directly.The change is self-contained to
libdd-data-pipelineand does not touchlibdd-shared-runtime; the sync facades keep using the existing owned-modeSharedRuntime::block_on.What changed
trace_exporter/mod.rssend,send_trace_chunks,shutdownare now thinblock_onfacades oversend_async,send_trace_chunks_asyncand the newshutdown_async.check_agent_infois nowasync(native + wasm); it awaits the stats pathand takes an owned status snapshot via
load_full()to avoid holding a!SendArcSwapguard across.await.send_deser— its deserialize-and-send logic already lives insend_async.trace_exporter/builder.rsbuild_async(the real builder body);buildis now ablock_onfacade that materializes the
SharedRuntimeup front so both share a singleinstance.
client_tel.start().await) instead ofblock_on.!SendHandle::enter()guard is scoped to a block so it drops before any.await, keeping the futureSend.trace_exporter/stats.rsstop_stats_computationandhandle_stats_enabledare nowasyncand awaitthe stats-worker shutdown directly instead of routing through
block_on.Notes / compatibility
send,send_trace_chunks,shutdown,build) areunchanged, so FFI callers are unaffected.
buildfacade is gated to native (#[cfg(not(target_arch = "wasm32"))]),matching the existing convention where
send/send_trace_chunksarenative-only and wasm consumers use the
_asyncvariants (block_ondoes notexist on wasm).
build_asyncis cross-platform.