[SLES-2907] chore(deps): bump dd-trace-rs to datadog-opentelemetry-v0.5.0#1302
Conversation
….5.0 Bumps datadog-opentelemetry from f51cefc4 (pre-v0.3.0) to 50bfea87 (v0.5.0), adding features = ["_unstable_propagation"] since the propagation module bottlecap uses is now feature-gated upstream. Bumps dogstatsd/datadog-fips/datadog-agent-config to the serverless-components commit that carries the matching dd-trace-rs pin (DataDog/serverless-components#144, currently unmerged - rev will be amended to the merged SHA before this PR leaves draft). v0.5.0 adds native B3 (single and multi-header) propagation support, fixing "Unknown trace propagation style: 'b3multi'" errors reported by customers (SLES-2907). Code changes required by the bump: - src/config/propagation_wrapper.rs: implement the new required PropagationConfig::trace_propagation_behavior_extract method (hardcoded to Continue, matching prior implicit behavior; bottlecap does not expose DD_TRACE_PROPAGATION_BEHAVIOR_EXTRACT). - src/traces/propagation/mod.rs: DatadogCompositePropagator::extract now returns ExtractResult instead of Option<SpanContext>; adapted the wrapper to match on it. - src/lifecycle/invocation/triggers/step_function_event.rs: the constants module re-export was removed upstream (moved to libdd-sampling internally); hardcoded the one test-only usage of SAMPLING_DECISION_MAKER_TAG_KEY ("_dd.p.dm") instead of adding a new dependency for it. Verified: cargo check/clippy/fmt clean, cargo test --lib 530/530 pass, dd-rust-license-tool check passes. --features fips hits a pre-existing local-macOS-only dylib issue in libddwaf-sys, confirmed identical on unmodified main.
|
🔄 Datadog auto-retried 3 jobs - 2 passed on retry 🔗 Commit SHA: 6b7e0ed | Docs | Datadog PR Page | Give us feedback! |
DataDog/serverless-components#144 merged as 56779dec9f4c9bcc48abcc9833ca4fa4b9d8d627. Re-pin dogstatsd/datadog-fips/datadog-agent-config to that commit instead of the pre-merge draft SHA, and regenerate Cargo.lock. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Updates Bottlecap’s tracing propagation stack to a newer datadog-opentelemetry (dd-trace-rs) revision to pick up native B3 (single/multi) propagation support and align related serverless-components dependencies, with small adapter changes to keep Bottlecap behavior consistent with the updated upstream APIs.
Changes:
- Bump
datadog-opentelemetrytodatadog-opentelemetry-v0.5.0and enable the upstream feature gate (_unstable_propagation) needed for Bottlecap’s propagation usage. - Adapt Bottlecap’s propagation wrapper to the new upstream APIs (
ExtractResultand the requiredPropagationConfig::trace_propagation_behavior_extract). - Remove reliance on an upstream re-exported constant in Step Function trigger tests by hardcoding the stable wire-protocol tag key; update 3rd-party license inventory accordingly.
Reviewed changes
Copilot reviewed 5 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| bottlecap/src/traces/propagation/mod.rs | Updates extraction adapter to handle upstream ExtractResult while preserving Bottlecap’s prior Option<SpanContext> behavior and baggage attachment. |
| bottlecap/src/lifecycle/invocation/triggers/step_function_event.rs | Replaces removed upstream constant re-export with a test-local hardcoded tag key. |
| bottlecap/src/config/propagation_wrapper.rs | Implements newly required PropagationConfig::trace_propagation_behavior_extract using upstream default behavior. |
| bottlecap/LICENSE-3rdparty.csv | Adds newly introduced transitive dependencies to the 3rd-party license inventory. |
| bottlecap/Cargo.toml | Bumps dd-trace-rs pin and aligns serverless-components git revs; enables required feature gate. |
| bottlecap/Cargo.lock | Locks the updated dependency graph produced by the bumps. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1303670371
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The b3/b3multi extractors in datadog-opentelemetry v0.5.0 return a full 128-bit trace_id but don't set the _dd.p.tid tag (unlike the Datadog format extractor). Downstream code casts trace_id to u64 and relies on that tag to avoid losing the high bits, so 128-bit B3 trace IDs were silently truncated to 64 bits when re-injected into headers or spans. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…1303) ## Overview Follows up on the `dd-trace-rs` v0.5.0 bump ([#1302](#1302)): bumps the shared `libdatadog` git rev (`libdd-capabilities`, `libdd-common`, `libdd-trace-protobuf`, `libdd-trace-utils`, `libdd-trace-normalization`, `libdd-trace-obfuscation`, `libdd-trace-stats`) from `a820699` to `85ce322a`, matching the exact versions `datadog-opentelemetry` v0.5.0 pulls from crates.io. Adds a `[patch.crates-io]` block redirecting those (and the other transitively-pulled `libdd-*` crates) to the same rev, collapsing what would otherwise be two compiled copies of each. This addresses the duplication [Copilot flagged on serverless-components#144](DataDog/serverless-components#144 (comment)) — see `bottlecap/LIBDATADOG_VERSION_ALIGNMENT.md` for the full writeup of options considered and why this one (patch + shared rev bump) was chosen over switching to crates.io versions directly (tried first, reverted — broke type identity for `ReplaceRule`/`Endpoint`/`Span`/etc. across the git-vs-registry boundary throughout the trace pipeline) or leaving the duplication as-is. ### Why not just add this to #1302? #1302 skipped this on purpose. The duplication only cost +256 bytes on the release binary (LTO strips the unreachable copy), while actually fixing it means an untested major-version bump across six libdatadog crates, including `libdd-trace-obfuscation` — the code that redacts sensitive data from spans. Not something to risk on the same PR as an urgent customer fix (SLES-2907, B3 propagation errors). This PR does that bump on its own, with its own tests. **Depends on [DataDog/serverless-components#145](DataDog/serverless-components#145 (which itself builds on #144, still draft) — the `dogstatsd`/`datadog-fips`/`datadog-agent-config` rev pin here must stay in sync with whatever commit that PR lands at. Opened as draft for that reason. JIRA: [SLES-2907](https://datadoghq.atlassian.net/browse/SLES-2907) ### Code changes at the new rev Most of the API changes in `SpanConcentrator` are just things the compiler forces on you, with no behavior change: - `new()` gained an obfuscation-config param. We pass `None` — bottlecap has never done client-side stats obfuscation. - `flush()` now returns `FlushResult { obfuscated_buckets, unobfuscated_buckets }` instead of a flat `Vec`. We concatenate both — obfuscation is off, so everything ends up in `unobfuscated_buckets` anyway. - `pb::TracerPayload` gained `container_debug`, `pb::ClientGroupedStats` gained `additional_metric_tags`. Added the missing fields to 3 struct literals so things compile; both are left at their defaults. `SpanConcentrator::new` also gained a cardinality-override param — the new rev defaults to capping trace-stats aggregation at 7,000 distinct keys per 10-second bucket, added in [DataDog/libdatadog#2158](DataDog/libdatadog#2158) to bound `SpanConcentrator`'s own memory use ([#2158](DataDog/libdatadog#2158) has the math: ~45.6 MB typical, ~700 MB worst case across 3 buckets with the limit on). This is an APM/trace-stats decision, unrelated to Datadog's custom-metrics cardinality limits. The scope of this PR is dependency consolidation, not adopting a new safety feature, so we pass `Some(usize::MAX)` to keep this rev bump behavior-neutral: no Lambda workload will ever produce `usize::MAX` distinct keys in a 10-second window, so stats collapsing never triggers, matching pre-bump behavior exactly. Passing `None` instead would opt into new behavior (collapsing above 7,000 keys into a generic `tracer_blocked_value` bucket for workloads that never hit that before) — worth considering on its own merits given Lambda's memory constraints, but that's a deliberate product/safety decision that deserves its own PR and review, not something to fold into a dependency bump. `test_no_cardinality_limit_applied` covers the unbounded behavior we're keeping. ## Testing - `cargo build --all-targets` — clean - `cargo test --all-targets` — 548/548 pass across all test binaries - `cargo clippy --all-targets -- -D warnings` — clean - `cargo fmt --all -- --check` — clean - `cargo tree --duplicates | grep ^libdd-` — empty (zero `libdd-*` duplicates) - `dd-rust-license-tool check` — passes - Verified against the real `serverless-components#145` commit (not a local `file://` override used during earlier iteration) [SLES-2907]: https://datadoghq.atlassian.net/browse/SLES-2907?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Overview
Bumps
datadog-opentelemetry(dd-trace-rs) fromf51cefc4(pre-v0.3.0) to50bfea87(datadog-opentelemetry-v0.5.0), addingfeatures = ["_unstable_propagation"]since thepropagationmodulebottlecap uses is now feature-gated upstream (was unconditionally public at
our old pin).
Also bumps
dogstatsd/datadog-fips/datadog-agent-configto theserverless-componentscommit that carries the matching dd-trace-rs pin —DataDog/serverless-components#144,
v0.5.0 adds native B3 (single- and multi-header) trace propagation support,
fixing
Failed to parse trace propagation style: Unknown trace propagation style: 'b3multi', ignoringerrors reported by a customer — seeSLES-2907.
Code changes required by the bump
src/config/propagation_wrapper.rs— implements the new requiredPropagationConfig::trace_propagation_behavior_extractmethod (hardcodedto
Continue, matching prior implicit behavior; bottlecap doesn't exposeDD_TRACE_PROPAGATION_BEHAVIOR_EXTRACT).src/traces/propagation/mod.rs—DatadogCompositePropagator::extractnowreturns
ExtractResultinstead ofOption<SpanContext>; adapted thewrapper to match on it (
Continue(ctx) -> Some(ctx), everything else ->None, preserving current behavior).src/lifecycle/invocation/triggers/step_function_event.rs— thedatadog_opentelemetry::constantsre-export was removed upstream (movedto
libdd-samplinginternally); hardcoded the one test-only usage ofSAMPLING_DECISION_MAKER_TAG_KEY("_dd.p.dm") rather than adding a newdependency for it.
Testing
cargo check --all-targets— cleancargo clippy --all-targets -- -D warnings— cleancargo fmt --all -- --check— cleancargo test --lib— 530/530 passdd-rust-license-tool check— passescargo tree --duplicates— no newdatadog-opentelemetry/tonic/prostduplication;
opentelemetry/opentelemetry_sdk/-semantic-conventionsdo pick up a new duplicate version (0.31 direct vs. 0.32 via dd-trace-rs) —
non-blocking, binary-size-only, bottlecap never shares those types across
the
datadog_opentelemetryboundary--features fipshits a pre-existing local-macOS-only dylib loading issuein
libddwaf-sys, confirmed identical on unmodifiedmain(needsLinux/CI, unrelated to this change)
Dependency graph:
