Skip to content

libdatadog update to 74284cac#3944

Open
dd-octo-sts[bot] wants to merge 1 commit into
masterfrom
bot/libdatadog-latest
Open

libdatadog update to 74284cac#3944
dd-octo-sts[bot] wants to merge 1 commit into
masterfrom
bot/libdatadog-latest

Conversation

@dd-octo-sts

@dd-octo-sts dd-octo-sts Bot commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

Summary

Automated update of the libdatadog submodule to the latest HEAD.

SHA
Previous 93e97238020b5cf1165b2583ec555d58307af3c1
New 74284cac76e9e6f8e4085b0029c851ec8d47b2f4

Full 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

⚠️ Adapted (API changes fixed)

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:

error: failed to load manifest for workspace member `.../components-rs`
  Caused by: failed to load manifest for dependency `datadog-remote-config`
  Caused by: failed to read `.../libdatadog/datadog-remote-config/Cargo.toml`
  Caused by: No such file or directory (os error 2)

This is the libdatadog change 82152fa58 refactor(datadog-remote-config): rename as libdd-remote-config (#2085) — the crate's directory and package name were renamed
from datadog-remote-config to libdd-remote-config. The downstream
cc: error: no such file or directory: 'target/debug/libdatadog_php.a' and
make: *** Error 2 lines in the C-link traces are secondary: the static library was
never 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 in
the 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:

  • compile tracing extension asan (×9), compile extension debug/debug-zts-asan
    (×3), compile tracing sidecar (×1), compile profiler extension (×1),
    pecl tests (×2) — all the manifest error above. Fixed.
  • aggregate tested versions (×1) — cascade aggregation job; fails because the
    compile jobs it depends on failed. Resolves once the compiles pass.
  • windows test_c [7.2], [7.3] (×2) — job_execution_timeout after 3600 s with no
    compilation 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 renamed
    datadog-remote-config = { path = "../libdatadog/datadog-remote-config" }
    libdd-remote-config = { path = "../libdatadog/libdd-remote-config" } to match the
    renamed 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 three use datadog_remote_config::…
    import statements to use libdd_remote_config::…. The module paths under the crate
    (config::dynamic, fetch, and the top-level re-exports default_registry,
    RemoteConfigCapabilities, RemoteConfigParsed, RemoteConfigProduct, Target) are
    unchanged — only the crate name changed. Verified all imported symbols still exist in
    libdd-remote-config and that its default features (client, https) still provide
    them.

  • cbindgen.tomlinclude list entry "datadog-remote-config"
    "libdd-remote-config" so cbindgen still expands that crate's types into the generated
    C header.

  • components-rs/bytes.rs — adapted to the v04 span VecMap refactor
    (74284cac7 refactor(span)!: use VecMap for meta/metrics/meta_struct (#2043)).
    SpanBytes::{meta, metrics, meta_struct} are now VecMap instead of HashMap, and
    VecMap has no remove method — it exposes remove_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; insert now 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 an
    optional frame_count: Option<usize> to the internal Experimental crash-info struct,
    set via the new builder method with_experimental_frame_count. We only re-export the
    crashtracker 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) — the
    FixedAggregationKey<T> struct we construct in components-rs/stats.rs still has
    exactly 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). The
    gating is internal to the concentrator, so no source change is required.

Flaky / ignored failures

  • windows test_c [7.2], [7.3]job_execution_timeout (3600 s) with no captured
    compilation 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

@dd-octo-sts dd-octo-sts Bot requested review from a team as code owners June 3, 2026 05:22
@dd-octo-sts dd-octo-sts Bot requested review from sameerank and typotter and removed request for a team June 3, 2026 05:22
@datadog-prod-us1-6

datadog-prod-us1-6 Bot commented Jun 3, 2026

Copy link
Copy Markdown

Pipelines  Tests

Fix all issues with BitsAI

⚠️ Warnings

🚦 56 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-php | ASAN test_c: [8.0, arm64]   View in Datadog   GitLab

🧪 2 Tests failed

tmp/build_extension/tests/ext/close_spans_until.phpt (Test DDTrace\close_spans_until) from PHP.tmp.build_extension.tests.ext   View in Datadog (Fix with Cursor)
--
     [ddtrace] [span] [%d] Switching to different SpanStack: %d
     int(1)
     int(0)
024&#43; [ddtrace] [span] [5027] Encoding span: Span { service: close_spans_until.php, name: close_spans_until.php, resource: close_spans_until.php, type: cli, trace_id: 17063002363982092257, span_id: 17063002363982092257, parent_id: 0, start: 1781071061183150219, duration: 12007058, error: 0, meta: VecMap { data: [(_dd.tags.process, entrypoint.basedir:ext,entrypoint.name:close_spans_until,entrypoint.type:script,entrypoint.workdir:dd-trace-php,runtime.sapi:cli), (runtime-id, 3ec23f31-3176-407a-9036-a0cc2900f663), (_dd.code_origin.type, entry), (_dd.code_origin.frames.0.file, tmp/build_extension/tests/ext/close_spans_until.php), (_dd.code_origin.frames.0.line, 1), (_dd.p.dm, -0), (_dd.p.tid, 6a28fcd500000000)], deduped: false }, metrics: VecMap { data: [(process_id, 5027.0), (_dd.agent_psr, 1.0), (_sampling_priority_v1, 1.0), (php.compilation.total_time_ms, 5.443), (php.memory.peak_usage_bytes, 0.0), (php.memory.peak_real_usage_bytes, 0.0)], deduped: false }, meta_struct: VecMap { data: [], deduped: false }, span_links: [], span_events: [] }
024- [ddtrace] [span] [%d] Encoding span: Span { service: close_spans_until.php, name: close_spans_until.php, resource: close_spans_until.php, type: cli, trace_id: %d, span_id: %d, parent_id: 0, start: %d, duration: %d, error: 0, meta: %s, metrics: %s, meta_struct: {}, span_links: [], span_events: [] }
     [ddtrace] [span] [%d] Encoding span: Span { service: close_spans_until.php, name: traced, resource: traced, type: cli, trace_id: %d, span_id: %d, parent_id: %d, start: %d, duration: %d, error: %d, meta: %s, metrics: %s, meta_struct: %s, span_links: %s, span_events: %s }
     [ddtrace] [span] [%d] Encoding span: Span { service: close_spans_until.php, name: , resource: , type: cli, trace_id: %d, span_id: %d, parent_id: %d, start: %d, duration: %d, error: %d, meta: %s, metrics: %s, meta_struct: %s, span_links: %s, span_events: %s }
     [ddtrace] [span] [%d] Encoding span: Span { service: close_spans_until.php, name: , resource: , type: cli, trace_id: %d, span_id: %d, parent_id: %d, start: %d, duration: %d, error: %d, meta: %s, metrics: %s, meta_struct: %s, span_links: %s, span_events: %s }
--
❄️ Known flaky: tmp/build_extension/tests/ext/background-sender/agent_sampling_sidecar.phpt (The sidecar trace flusher sender informs about changes to the agent sample rate) from PHP.tmp.build_extension.tests.ext.background.sender   View in Datadog (Fix with Cursor)
001&#43; [ddtrace] [libdd_trace_utils::span::vec_map] [5319] VecMap not deduped before encoding. Performing defensive on-the-fly dedup
     Initial sampling: 1
--

Not introduced in this PR.

DataDog/apm-reliability/dd-trace-php | ASAN test_c: [8.4, arm64]   View in Datadog   GitLab

🧪 2 Tests failed

tmp/build_extension/tests/ext/close_spans_until.phpt (Test DDTrace\close_spans_until) from php.tmp.build_extension.tests.ext   View in Datadog (Fix with Cursor)
--
     [ddtrace] [span] [%d] Switching to different SpanStack: %d
     int(1)
     int(0)
024- [ddtrace] [span] [%d] Encoding span: Span { service: close_spans_until.php, name: close_spans_until.php, resource: close_spans_until.php, type: cli, trace_id: %d, span_id: %d, parent_id: 0, start: %d, duration: %d, error: 0, meta: %s, metrics: %s, meta_struct: {}, span_links: [], span_events: [] }
024&#43; [ddtrace] [span] [5419] Encoding span: Span { service: close_spans_until.php, name: close_spans_until.php, resource: close_spans_until.php, type: cli, trace_id: 1471070102553213181, span_id: 1471070102553213181, parent_id: 0, start: 1781071217564435385, duration: 11161392, error: 0, meta: VecMap { data: [(_dd.tags.process, entrypoint.basedir:ext,entrypoint.name:close_spans_until,entrypoint.type:script,entrypoint.workdir:dd-trace-php,runtime.sapi:cli), (runtime-id, 0d63648f-6a6b-4562-88a0-413b88d0dd70), (_dd.code_origin.type, entry), (_dd.code_origin.frames.0.file, tmp/build_extension/tests/ext/close_spans_until.php), (_dd.code_origin.frames.0.line, 1), (_dd.p.dm, -0), (_dd.p.tid, 6a28fd7100000000)], deduped: false }, metrics: VecMap { data: [(process_id, 5419.0), (_dd.agent_psr, 1.0), (_sampling_priority_v1, 1.0), (php.compilation.total_time_ms, 5.527), (php.memory.peak_usage_bytes, 0.0), (php.memory.peak_real_usage_bytes, 0.0)], deduped: false }, meta_struct: VecMap { data: [], deduped: false }, span_links: [], span_events: [] }
     [ddtrace] [span] [5419] Encoding span: Span { service: close_spans_until.php, name: traced, resource: traced, type: cli, trace_id: 1471070102553213181, span_id: 11933390267969240685, parent_id: 1471070102553213181, start: 1781071217572003293, duration: 3166113, error: 0, meta: VecMap { data: [], deduped: false }, metrics: VecMap { data: [], deduped: false }, meta_struct: VecMap { data: [], deduped: false }, span_links: [], span_events: [] }
     [ddtrace] [span] [5419] Encoding span: Span { service: close_spans_until.php, name: , resource: , type: cli, trace_id: 1471070102553213181, span_id: 14369559430815746229, parent_id: 11933390267969240685, start: 1781071217573679471, duration: 1272596, error: 0, meta: VecMap { data: [], deduped: false }, metrics: VecMap { data: [], deduped: false }, meta_struct: VecMap { data: [], deduped: false }, span_links: [], span_events: [] }
     [ddtrace] [span] [5419] Encoding span: Span { service: close_spans_until.php, name: , resource: , type: cli, trace_id: 1471070102553213181, span_id: 11843218927798182865, parent_id: 14369559430815746229, start: 1781071217573953000, duration: 740258, error: 0, meta: VecMap { data: [], deduped: false }, metrics: VecMap { data: [], deduped: false }, meta_struct: VecMap { data: [], deduped: false }, span_links: [], span_events: [] }
     [ddtrace] [span] [5419] Encoding span: Span { service: close_spans_until.php, name: , resource: , type: cli, trace_id: 1471070102553213181, span_id: 1030189614171315220, parent_id: 11843218927798182865, start: 1781071217574224880, duration: 258120, error: 0, meta: VecMap { data: [], deduped: false }, metrics: VecMap { data: [], deduped: false }, meta_struct: VecMap { data: [], deduped: false }, span_links: [], span_events: [] }
...
❄️ Known flaky: tmp/build_extension/tests/ext/background-sender/agent_sampling_sidecar.phpt (The sidecar trace flusher sender informs about changes to the agent sample rate) from php.tmp.build_extension.tests.ext.background.sender   View in Datadog (Fix with Cursor)
001&#43; [ddtrace] [libdd_trace_utils::span::vec_map] [4610] VecMap not deduped before encoding. Performing defensive on-the-fly dedup
     Initial sampling: 1
--

Not introduced in this PR.

DataDog/apm-reliability/dd-trace-php | ASAN Opcache tests: [8.5]   View in Datadog   GitLab

View all 56 failed jobs.

ℹ️ Info

No other issues found (see more)

❄️ No new flaky tests detected

🔄 Datadog auto-retried 6 jobs - 2 passed on retry View in Datadog

🎯 Code Coverage (details)
Patch Coverage: 100.00%
Overall Coverage: 54.13% (-0.03%)

Useful? React with 👍 / 👎

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 799e351 | Docs | Datadog PR Page | Give us feedback!

@dd-octo-sts dd-octo-sts Bot changed the title libdatadog update to a1da9fc3 libdatadog update to 48da0d82 Jun 4, 2026
@dd-octo-sts dd-octo-sts Bot force-pushed the bot/libdatadog-latest branch 2 times, most recently from bbf5aea to 5c82d3b Compare June 5, 2026 05:10
@dd-octo-sts dd-octo-sts Bot changed the title libdatadog update to 48da0d82 libdatadog update to a76412cc Jun 5, 2026
@dd-octo-sts dd-octo-sts Bot changed the title libdatadog update to a76412cc libdatadog update to 98016adb Jun 6, 2026
@dd-octo-sts dd-octo-sts Bot force-pushed the bot/libdatadog-latest branch 3 times, most recently from 61593df to 6c9ce4c Compare June 8, 2026 07:41
@dd-octo-sts dd-octo-sts Bot changed the title libdatadog update to 98016adb libdatadog update to cfb46bd8 Jun 9, 2026
@dd-octo-sts dd-octo-sts Bot force-pushed the bot/libdatadog-latest branch from 6c9ce4c to 6cbfc00 Compare June 9, 2026 06:16
@dd-octo-sts dd-octo-sts Bot force-pushed the bot/libdatadog-latest branch from 6cbfc00 to 799e351 Compare June 10, 2026 05:04
@dd-octo-sts dd-octo-sts Bot changed the title libdatadog update to cfb46bd8 libdatadog update to 74284cac Jun 10, 2026
@dd-octo-sts dd-octo-sts Bot requested a review from a team as a code owner June 10, 2026 05:04
@pr-commenter

pr-commenter Bot commented Jun 10, 2026

Copy link
Copy Markdown

Benchmarks [ tracer ]

Benchmark execution time: 2026-06-10 06:23:33

Comparing candidate commit 799e351 in PR branch bot/libdatadog-latest with baseline commit 08d5785 in branch master.

Found 6 performance improvements and 0 performance regressions! Performance is the same for 187 metrics, 1 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:PDOBench/benchPDOOverhead

  • 🟩 execution_time [-11.724µs; -8.992µs] or [-4.419%; -3.389%]

scenario:PDOBench/benchPDOOverheadWithDBM

  • 🟩 execution_time [-11.101µs; -8.579µs] or [-4.181%; -3.231%]

scenario:PHPRedisBench/benchRedisOverhead

  • 🟩 execution_time [-58.869µs; -46.253µs] or [-5.534%; -4.348%]

scenario:SpanBench/benchOpenTelemetryInteroperability-opcache

  • 🟩 execution_time [-34.753µs; -28.499µs] or [-8.771%; -7.193%]

scenario:TraceSerializationBench/benchSerializeTrace

  • 🟩 execution_time [-54.164µs; -43.336µs] or [-10.462%; -8.371%]

scenario:TraceSerializationBench/benchSerializeTrace-opcache

  • 🟩 execution_time [-52.803µs; -43.297µs] or [-11.725%; -9.614%]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants