libdatadog update to 9d6b2ffb

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	378be45c30e9c62a1203c4cc2069aaaf8d1f4673
New	9d6b2ffb3d86bb052a822a5e9a9bcfeb62514983

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

---

libdatadog Integration Report

libdatadog SHA: 9d6b2ffb3d86bb052a822a5e9a9bcfeb62514983
Analysis date: 2026-08-24

Overall status

✅ Clean update (no API adaptation required) — with one caveat: the log for
test_extension_ci: [8.0] could not be retrieved in this environment, so that
failure is classified on circumstantial evidence rather than a root-caused
stack trace. See "Flaky / ignored failures".

Build & test summary

Update range: 378be45c3..9d6b2ffb3 (4 commits).

Sub-pipeline	Result
shared-trigger	✅ success
profiler-trigger	✅ success
appsec-trigger	✅ success
tracer-trigger	❌ 1 job: test_extension_ci: [8.0]
package-trigger	❌ 1 job: System Tests: [php-fpm-7.1, tracer-release]

No compilation failures anywhere. tmp/artifacts/traces/ is empty, and both
failing jobs are downstream of successful compile jobs — test_extension_ci
needs: "compile extension: debug" with artifacts: true
(.gitlab/generate-tracer.php:364), and System Tests needs
package extension / datadog-setup.php (.gitlab/generate-package.php:1280).
Every Rust and C target — tracer, profiler, appsec, shared, packaging, on both
amd64 and arm64 — built against the new libdatadog. That is the decisive signal
that no FFI or Rust API surface we consume changed.

Two further jobs (ASAN test_c: [8.0, arm64], Loader test on amd64 libc: [8.2, zts, amd64, true]) failed on the first attempt and passed on retry.

API-surface review of the 4 new commits

I diffed the full range excluding docs/CI/lockfiles and reviewed every source
hunk against our call sites:

• 9d6b2ffb3 feat(compression): use zrip for wasm targets (Zero pad the tid and exclude it from OTel tracestate #2386) — every
  behavioural hunk is #[cfg(target_arch = "wasm32")]; the native branch of
  libdd-trace-utils/src/send_with_retry/compression.rs,
  libdd-profiling/src/profiles/compressor.rs and
  libdd-data-pipeline/src/trace_exporter/mod.rs is byte-equivalent in effect
  (the zstd::Encoder path was only re-indented into a let result = …).
  libdd-trace-utils gained an internal zstd feature that re-exports
  dep:zstd + dep:zrip; compression = ["zstd"] still resolves to real zstd
  on native targets. Wire format and Content-Encoding unchanged.
• 542a34eff fix(rc)!: fixup rc to be wasm compatible (fix(profiler) do not emit profiles when profiler is disabled #2393) — marked
  breaking, but the break is confined to the agentless feature:
  NativeAgentlessFetcher now aliases
  AgentlessFetcher<libdd_capabilities_impl::NativeCapabilities> instead of
  NativeHttpClient, and AgentlessFetcher<C> / FetcherMode<C> gained a
  SleepCapability bound. components-rs/Cargo.toml:20 takes
  libdd-remote-config with default features (client, https) — not
  agentless — and grep over all non-libdatadog *.rs/*.toml finds zero
  references to NativeHttpClient, NativeCapabilities, AgentlessFetcher, or
  libdd_capabilities. Inert for us. The manifest also moved
  libdd-capabilities-impl under cfg(not(target_arch = "wasm32")), which is
  still satisfied for every target we build.
• 417633890 chore(ci): add blocking cargo-deny bans gate (Fix #2312: More precise installer error message #2387) — CI-only
  for libdatadog. Side effect: it relaxed
  datadog-sidecar/Cargo.toml's arrayref = "=0.3.9" back to "0.3.7", since
  the compromised arrayref 0.3.10 is now blocked by deny.toml:8. Both
  Cargo.lock and libdatadog/Cargo.lock still resolve arrayref 0.3.9, so
  nothing changes for our builds. Noted below as a supply-chain observation.
• e235e768c fix(crashtracker): hold the collector connection open through
  symbolization (Implement extended sampling #2384) — the only native behavioural change in the range.
  receive_report_from_stream now borrows the stream instead of consuming it,
  and receiver_entry_point drops it after resolve_frames. Both are
  pub(crate); no FFI symbol moved. The observable effect is that a crashing
  process stays blocked in wait_for_pollhup until symbolization finishes
  (upstream measured this as an ~8% → 0% flake reduction in their own
  bin_test). It lengthens the crash pause slightly, which is worth keeping in
  mind for tests/ext/crashtracker_*.phpt, but it is a reliability fix, not a
  regression.

Non-trivial changes made

No code changes required. The only working-tree modification is the
libdatadog submodule pointer bump.

Identified libdatadog issues

None identified.

Adjacent observation (not a bug, no action needed now): 417633890 replaced the
exact pin arrayref = "=0.3.9" with the caret requirement arrayref = "0.3.7"
in datadog-sidecar/Cargo.toml, relying on the new cargo-deny bans gate to
block the malicious 0.3.10. That gate runs in libdatadog's GitHub Actions, not
in dd-trace-php's pipeline. We are protected today only because
Cargo.lock:134-135 pins 0.3.9; a future cargo update -p arrayref here
could pull 0.3.10 without anything in our CI objecting.

Flaky / ignored failures

System Tests: [php-fpm-7.1, tracer-release] — ignore, infrastructure
timeout. failure_reason is stuck_or_timeout_failure with duration
15453 s (4 h 17 m) against the job's declared timeout: 4h
(.gitlab/generate-package.php:1387). The job produced no artifacts and no
trace. This template is generated for 26 weblog variants
(.gitlab/generate-package.php:1371-1382); exactly one of them — a
docker-in-docker microVM runner — hit the wall clock. A libdatadog change that
hung the tracer would not spare the other 25 variants. The job name also matches
System Tests:* in .gitlab/flaky-jobs.txt:54, the repo's own list of jobs
excluded from the merge gate.

test_extension_ci: [8.0] — most likely flaky; classified with lower
confidence than I would like, because I could not read the log.

Evidence available: script_failure, tracer sub-pipeline, PHP 8.0 / amd64
only. The same template runs for every supported PHP minor
(.gitlab/generate-tracer.php:363-364) and 8.0 was the only one to fail; the
compile extension: debug job it depends on succeeded. test_extension_ci:* is
listed in .gitlab/flaky-jobs.txt:60. Combined with the API review above — the
only native runtime change in the range is a crashtracker fix that reduces
flakiness — there is no plausible mechanism by which these four commits break
PHP 8.0 and leave 7.0–7.4 and 8.1–8.5 green, since libdatadog is compiled
identically for all of them.

Evidence I could not obtain, and why: this analysis runs inside a GitLab job
with no GITLAB_PERSONAL_ACCESS_TOKEN; GET /projects/355/jobs/1975665742/trace
with JOB-TOKEN: $CI_JOB_TOKEN returns 401 Unauthorized, and the 104 MB
artifact archive (which contains the JUnit XML and run-tests.php diffs) is
behind the same auth. tmp/artifacts/traces/ only carries logs for compilation
failures, and this was a test failure. I therefore cannot name the failing
.phpt, and per the repo's investigation rules I have not verified the failure
against git merge-base HEAD origin/master. Recommended follow-up before
merging: open
https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-php/-/jobs/1975665742
and confirm the failing test. If it is one of tests/ext/crashtracker_*.phpt,
re-read the e235e768c note above — the longer crash pause is the one change in
this range that could plausibly interact with those tests' timing.

Note this job had already been retried once and failed again, so "flaky" here
means intermittently failing rather than a one-off.

---

/cc @bwoebi

[datadog-datadog-prod-us1-2]

 

✨ Unblock PR with BitsAI

⚠️ Warnings

🚦 11 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-php | test_extension_ci: [8.1] — 🔧 Needs a code fix, caused by this PR

View more details · View in GitLab

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

View more details · View in GitLab

DataDog/apm-reliability/dd-trace-php | test_extension_ci: [8.5] — 🔧 Needs a code fix, caused by this PR

View more details · View in GitLab

View all 11 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.66% (-0.01%)

Useful? React with 👍 / 👎

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