libdatadog update to 74284cac#3944
Conversation
|
bbf5aea to
5c82d3b
Compare
61593df to
6c9ce4c
Compare
6c9ce4c to
6cbfc00
Compare
Automated update by CI pipeline https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-php/-/pipelines/117884181 Full CI result: ❌ 19 job(s) failed
6cbfc00 to
799e351
Compare
Benchmarks [ tracer ]Benchmark execution time: 2026-06-10 06:23:33 Comparing candidate commit 799e351 in PR branch Found 6 performance improvements and 0 performance regressions! Performance is the same for 187 metrics, 1 unstable metrics.
|
Summary
Automated update of the libdatadog submodule to the latest HEAD.
93e97238020b5cf1165b2583ec555d58307af3c174284cac76e9e6f8e4085b0029c851ec8d47b2f4Full CI result: ❌ 19 job(s) failed
CI pipeline: https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-php/-/pipelines/117884181
libdatadog Integration Report
libdatadog SHA: 74284cac76e9e6f8e4085b0029c851ec8d47b2f4
Analysis date: 2026-06-10
Overall status
Build & test summary
All 19 persistent CI failures share a single root cause: every Rust build (tracer
extension, ASAN extension, sidecar, profiler, PECL builds) failed immediately when
Cargo tried to load the workspace, before any of our code was compiled:
This is the libdatadog change
82152fa58 refactor(datadog-remote-config): rename as libdd-remote-config (#2085)— the crate's directory and package name were renamedfrom
datadog-remote-configtolibdd-remote-config. The downstreamcc: error: no such file or directory: 'target/debug/libdatadog_php.a'andmake: *** Error 2lines in the C-link traces are secondary: the static library wasnever produced because Cargo aborted on the manifest error.
Because Cargo could not even load the workspace, no later compile errors were visible in
the logs. I therefore also audited our code against every other breaking (
!) change inthe changelog and found one more real incompatibility (VecMap span fields, #2043) plus
two that do not affect us (details below). After the fixes the workspace loads and
all reachable call sites use the current API.
Failure breakdown:
(×3), compile tracing sidecar (×1), compile profiler extension (×1),
pecl tests (×2) — all the manifest error above. Fixed.
compile jobs it depends on failed. Resolves once the compiles pass.
job_execution_timeoutafter 3600 s with nocompilation error trace captured. The Windows builds run the same Cargo workspace, so
the most likely explanation is the same manifest failure (or a slow/hung build around
it); these should be re-evaluated after the fix. No Windows-specific API issue was
identified.
Non-trivial changes made
components-rs/Cargo.toml— dependency key/path renameddatadog-remote-config = { path = "../libdatadog/datadog-remote-config" }→libdd-remote-config = { path = "../libdatadog/libdd-remote-config" }to match therenamed crate (Upgrade ASM to v0.9.0 #2085). The repo convention is to use each crate's real package name as
the dependency key (no
package =aliases), so the key was renamed to match.components-rs/remote_config.rs— updated the threeuse datadog_remote_config::…import statements to
use libdd_remote_config::…. The module paths under the crate(
config::dynamic,fetch, and the top-level re-exportsdefault_registry,RemoteConfigCapabilities,RemoteConfigParsed,RemoteConfigProduct,Target) areunchanged — only the crate name changed. Verified all imported symbols still exist in
libdd-remote-configand that its default features (client,https) still providethem.
cbindgen.toml—includelist entry"datadog-remote-config"→"libdd-remote-config"so cbindgen still expands that crate's types into the generatedC header.
components-rs/bytes.rs— adapted to the v04 spanVecMaprefactor(
74284cac7 refactor(span)!: use VecMap for meta/metrics/meta_struct (#2043)).SpanBytes::{meta, metrics, meta_struct}are nowVecMapinstead ofHashMap, andVecMaphas noremovemethod — it exposesremove_slow(same<Q>(&mut self, key: &Q)signature, returns()). Replaced the four.remove(&…)call sites(
ddog_del_span_meta_{zstr,str},ddog_del_span_metrics_{zstr,str}) with.remove_slow(&…). The remaining VecMap operations we use (insert,get,contains_key) are still present with compatible signatures;insertnow returns()but every call site already discards the return value.
Identified libdatadog issues
None identified. All observed breakage is the expected fallout of intentional,
changelog-documented refactors, and each had a clear current API to migrate to.
Other breaking changelog changes audited (no change needed)
feat(crashtracking)!: add experimental frame count field (#2099)— adds anoptional
frame_count: Option<usize>to the internalExperimentalcrash-info struct,set via the new builder method
with_experimental_frame_count. We only re-export thecrashtracker FFI (
pub use libdd_crashtracker_ffi::*) and never construct that struct,so this is additive and harmless for us.
feat(stats)!: add endpoint gating to client-side stats (#2040)— theFixedAggregationKey<T>struct we construct incomponents-rs/stats.rsstill hasexactly the 12 fields we set (
service_name,resource_name,operation_name,span_type,span_kind,http_method,http_endpoint,service_source,http_status_code,grpc_status_code,is_synthetics_request,is_trace_root). Thegating is internal to the concentrator, so no source change is required.
Flaky / ignored failures
job_execution_timeout(3600 s) with no capturedcompilation error. Treated as a consequence of the workspace-load failure / build
slowness rather than an independent, Windows-specific API break. Should pass on re-run
now that the manifest loads; flagged here for a confirmation run.
/cc @bwoebi