libdatadog update to aab513c2

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	$LIBDATADOG_PINNED_SHA
New	aab513c2e3d6a9926ea00ec065e008fbb0c40591

Full CI result: ❌ 4 job(s) failed
CI pipeline: https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-php/-/pipelines/131801566

---

libdatadog Integration Report

libdatadog SHA: aab513c2e3d6a9926ea00ec065e008fbb0c40591 (v41.0.0-18-gaab513c2e)
Analysis date: 2026-08-19

Overall status

⚠️ Adapted (API changes fixed) — the one API change in this bump (the
datadog-ipc → libdd-ipc crate rename) is already adapted in HEAD
(commit 30166920e), and that adaptation is complete. No further code
changes were required in this round. All 4 remaining CI failures are
infrastructure / known-flaky jobs, not libdatadog incompatibilities.

Build & test summary

What actually changed in libdatadog

The submodule moved a8bdcdb0c → aab513c2e, which is only 3 commits:

Commit	Title	Nature
fe7124662	refactor(datadog-ipc): prepare datadog-ipc* crates for publishing (#2359)	Pure crate rename
150809215	fix: bump libdd trace stats internal dep (#2367)	Version-metadata alignment in libdd-ipc/Cargo.toml
aab513c2e	chore: add manual trigger for validation after fix (#2366)	GitHub Actions workflow only

(tmp/artifacts/libdatadog_changelog.txt is a flat git log -n 100 of
libdatadog main, so it lists many older v38 → v41 commits that were
already integrated by earlier bumps. The delta relevant to this update is
the 3 commits above, computed with
git -C libdatadog log --oneline a8bdcdb0c..aab513c2e.)

I verified the delta carries no functional change:

git -C libdatadog diff --stat a8bdcdb0c..aab513c2e   # 70 files, 186 insertions(+), 183 deletions(-)
git -C libdatadog diff a8bdcdb0c..aab513c2e -- '*.rs' \
  | grep -E '^[-+]' | grep -vE '^(\+\+\+|---)' \
  | grep -viE 'datadog_ipc|datadog-ipc|libdd_ipc|libdd-ipc'

Every .rs source file under the renamed crate has a | 0 diffstat (pure
git mv); the only surviving hunks after filtering out the identifier rename
are use-block reflows from rustfmt. All inter-crate deps are path
dependencies, so the libdd-trace-stats 6.0.0 → 7.0.0 metadata bump in #2367
cannot resolve a different crate version. Net: no code path in libdatadog
behaves differently than at a8bdcdb0c.

Compilation

No compilation failures anywhere. tmp/artifacts/traces/ — which the
collector populates with log tails for build/compile failures — is empty, and
no failed job is in a compile/build stage. Every tracer, appsec, profiler,
shared and package build job succeeded, including compile extension across
all 11 PHP targets (7.0–8.5), the Windows build, and cbindgen header
generation.

ASAN test_c: [8.3, amd64] failed on its first attempt and passed on
retry, so the ASAN build and C test suite are clean.

Remaining failures

Job	Sub-pipeline	Stage	failure_reason	Classification
test_extension_ci: [8.0]	tracer	test	script_failure	Ignore — known-flaky
bundle for reliability env	package	shared-pipeline-build	runner_system_failure	Ignore — infra
publish docker image for system tests	package	release	script_failure	Ignore — external resource
installer tests	package	verify	script_failure	Ignore — known-flaky

See "Flaky / ignored failures" for the per-job reasoning.

Non-trivial changes made

No code changes required in this round.

The single API change in this bump — libdatadog #2359 renaming the
datadog-ipc and datadog-ipc-macros crates (to libdd-ipc /
libdd-ipc-macros) so they can be published to crates.io — was already
adapted in the update commit 30166920e itself. I re-audited that adaptation
and confirm it is complete:

File	Change	Verified
components-rs/Cargo.toml:17	datadog-ipc dep → libdd-ipc = { path = "../libdatadog/libdd-ipc" }	✅
components-rs/sidecar.rs:12	datadog_ipc::rate_limiter::{AnyLimiter, ShmLimiterMemory} → libdd_ipc::…	✅ symbols exist at libdatadog/libdd-ipc/src/rate_limiter.rs
components-rs/stats.rs:11	datadog_ipc::shm_stats::{OwnedShmSpanInput, ShmSpanConcentrator, ShmSpanInput, MAX_PEER_TAGS} → libdd_ipc::…	✅ all four at libdatadog/libdd-ipc/src/shm_stats.rs:69,303,321,355
components-rs/telemetry.rs:9-10	datadog_ipc::platform::NamedShmHandle, datadog_ipc::one_way_shared_memory::{open_named_shm, OneWayShmReader} → libdd_ipc::…	✅
cbindgen.toml:43	include list entry datadog-ipc → libdd-ipc	✅
Makefile:51	RUST_FILES glob: datadog-ipc,datadog-ipc-macros → libdd-ipc,libdd-ipc-macros; -not -path "*/datadog-ipc/build.rs" → */libdd-ipc/build.rs	✅ all 32 globbed crate dirs and libdd-ipc/build.rs exist in the new tree
Cargo.lock	regenerated (libdd-ipc, libdd-ipc-macros nodes)	✅

Completeness checks I ran:

• grep -rn --exclude-dir=libdatadog -E 'datadog[_-]ipc' . — the only
  remaining hits are the sidecar process/service name
  datadog-ipc-helper (in .claude/debugging/*.md,
  tests/ext/telemetry/{simple,broken_pipe}.phpt,
  tests/ext/appsec/{sca,agentic_onboarding}_test.inc,
  appsec/tests/integration/.../TelemetryHelpers.groovy). That name is
  unchanged by Retain tracestate from tracecontext if extracted at all #2359 — it is still hardcoded in
  libdatadog/datadog-sidecar/src/self_telemetry.rs:252,
  unix.rs:156 and windows.rs:111, so those references remain correct and
  must not be renamed.
• Every libdd_* / datadog_* import across components-rs/*.rs resolves in
  the new tree — I spot-checked the paths touched by the !-marked breaking
  changes in the wider changelog (libdd_trace_protobuf::pb::Trilean,
  libdd_trace_stats::span_concentrator::FixedAggregationKey,
  libdd_trace_utils::span::v04::SpanBytes,
  libdd_trace_utils::trace_filter::{Span, TraceFilterer},
  libdd_data_pipeline::agent_info::schema::AgentInfoStruct) and all are
  present. Consistent with the clean compile across the whole matrix.
• Cargo.toml (root workspace) needs no entry — components-rs is the only
  consumer.

Identified libdatadog issues

None identified.

No panic, regression, or unexpected behaviour originating inside libdatadog
was observed. Given that the 3-commit delta contains no functional change
(evidence above), there is no libdatadog behavioural surface in this bump that
could regress.

Flaky / ignored failures

bundle for reliability env (package, shared-pipeline-build) —
failure_reason: runner_system_failure, 65 s. GitLab classified this as a
runner/infrastructure fault, not a script fault. The job body
(.gitlab/generate-package.php:1717) is pure shell: write upstream.env,
mv a prebuilt tarball, tar it. It compiles nothing and links nothing
against libdatadog, and its upstream package extension dependency succeeded.
The job is also declared when: manual / allow_failure: true outside nightly
builds. → Infrastructure flake.

publish docker image for system tests (package, release) —
allow_failure: true. Per .gitlab/generate-package.php:1627, this job
consumes a dd-octo-sts GitHub token from the (also allow_failure: true)
publish docker image for system tests (token) job, calls the GitHub REST
API, and docker buildx --pushes a multi-arch image to
ghcr.io/datadog/dd-trace-php/dd-library-php. GIT_STRATEGY: none — it never
even checks out our source. Every failure mode here is an external resource
(token minting, GitHub API, GHCR push) or the transient
resource_group: publish-system-tests-image-… lock. → External resource
issue.

installer tests (package, verify) — runs
make -C dockerfiles/verify_packages test_installer in docker-in-docker over
already-built packages. It is listed verbatim in .gitlab/flaky-jobs.txt:30
as a job excluded from the merge gate, i.e. the repo already tracks it as
flaky. It installs packages across several distro images, so it is network- and
DinD-sensitive. → Known-flaky.

test_extension_ci: [8.0] (tracer, test) — matched by
test_extension_ci:* in .gitlab/flaky-jobs.txt:88, also excluded from the
merge gate. Two independent arguments that this is not libdatadog-related:

1. Version isolation. The matrix runs all 11 targets (7.0 … 8.5,
   .gitlab/generate-common.php:5-19) and only 8.0 failed. Nothing in
   libdatadog is PHP-version-specific, and 8.0 is not special with respect to
   the trace-sender split either — DD_SIDECAR_TRACE_SENDER_DEFAULT puts
   7.0–8.2 on the in-process tracer/coms.c sender, and 7.0–7.4, 8.1 and 8.2
   all passed on the same sender path. A libdatadog regression would not
   single out one ABI.
2. No behavioural delta to regress. The 3-commit libdatadog delta is a
   mechanical rename (evidence in "Build & test summary"). There is no changed
   code path for a test to catch.

The job's second half is the more failure-prone one — make test_extension_ci (Makefile:205-215) runs the .phpt suite twice, the
second time under valgrind with MAX_TEST_PARALLELISM=4 and a hard ! grep '^LEAKED TEST SUMMARY' gate, which is the usual source of this job's
timing-sensitive noise.

Limitation of this analysis, stated explicitly

Project rule ¶7 asks that a failure not be called pre-existing/unrelated
without reproducing it at git merge-base HEAD origin/master. I could not do
that here: this environment has no Rust/PHP toolchain and no build or test
commands available, and job logs are not retrievable
(GET /projects/355/jobs/<id>/trace returns 401 Unauthorized with the
available CI_JOB_TOKEN; tmp/artifacts/traces/ is empty because the
collector only captures tails for compilation failures). In place of a
merge-base test run, the argument above rests on (a) the inspected libdatadog
diff containing no functional change, and (b) test_extension_ci:* and
installer tests already being on the repo's own flaky list. Two of the four
failures are additionally corroborated by GitLab metadata
(runner_system_failure) and by the jobs being allow_failure: true
publish-only steps.

One further corroborating data point: HEAD's own commit message records
that the immediately preceding pipeline over this identical tree
(131775866) finished with 1 failed job, whereas this pipeline
(131801566) reports 4. Identical code with a different failure set across
runs is direct evidence of nondeterministic CI, not of a code defect. Note the
counterweight, for honesty: test_extension_ci: [8.0] failed and failed
again on retry within this pipeline (tmp/artifacts/retried_jobs.tsv), so it
is either deterministic-but-preexisting or an environment condition that
persisted across both attempts. Confirming which requires the job log.

Recommended follow-up (needs a machine that can run the suite): pull the
log for job
https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-php/-/jobs/1963935211
to identify the failing .phpt, then run that single test at
git merge-base HEAD origin/master for PHP 8.0 to confirm it is pre-existing.
Nothing in this bump should be blocked on it.

---

/cc @bwoebi

[datadog-datadog-prod-us1-2]

 

✨ Unblock PR with BitsAI

⚠️ Warnings

🚦 12 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-php | ASAN test_c with multiple observers: [8.0] — 🔧 Needs a code fix, caused by this PR

View in Datadog · View in GitLab

DataDog/apm-reliability/dd-trace-php | ASAN test_c: [7.4, arm64] — 🔧 Needs a code fix, caused by this PR

View in Datadog · View in GitLab

DataDog/apm-reliability/dd-trace-php | ASAN test_c: [8.2, amd64] — 🔧 Needs a code fix, caused by this PR

View in Datadog · View in GitLab

View all 12 failed jobs.

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

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

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: f0d39c2 | Docs | View more details | Give us feedback!}

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2026-08-19 21:01:11

Comparing candidate commit f0d39c2 in PR branch bot/libdatadog-latest with baseline commit a1ed3e5 in branch master.

Found 0 performance improvements and 2 performance regressions! Performance is the same for 192 metrics, 0 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:MessagePackSerializationBench/benchMessagePackSerialization

• 🟥 execution_time [+5.474µs; +7.626µs] or [+5.265%; +7.336%]

scenario:MessagePackSerializationBench/benchMessagePackSerialization-opcache

• 🟥 execution_time [+5.175µs; +7.545µs] or [+4.740%; +6.910%]