libdatadog update to a1da9fc3

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	a84923e5ec124efb59e413adac98afb9546a490b
New	a1da9fc35a6e46fb0cbe016da3f56df3c1b583d1

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

---

libdatadog Integration Report

libdatadog SHA: a1da9fc35a6e46fb0cbe016da3f56df3c1b583d1
Analysis date: 2026-06-03

Overall status

✅ Clean update

No API incompatibilities were found. The dd-trace-php Rust/C sources compile and
link against libdatadog a1da9fc without modification. The 27 failing jobs are all
runtime/infrastructure failures (Windows job timeouts and the externally-maintained
System Tests suite), not compilation or API-surface breakage. No code changes were made.

Build & test summary

The new libdatadog only carries two commits since the pinned SHA:

• a1da9fc35 feat: cross-language LTO to inline C TLS shim into Rust FFI (Fix system ini handling of invalid values in zai config #1982)
• 43a5c6b87 feat(data-pipeline): move the async boundary up (feat(ci) accelerates Rust builds and tests by using the build cache #2064)

Neither produced a compile error in our tree.

Sub-pipeline outcomes (from bridges.json):

Sub-pipeline	Result	Notes
shared-trigger	✅	Builds + tests against libdatadog FFI — clean
profiler-trigger	✅	Profiling FFI consumer — clean
appsec-trigger	✅	AppSec FFI consumer — clean
tracer-trigger	❌	Only windows test_c [7.2] and [7.3] failed — both timeouts
package-trigger	❌	Only System Tests (verify stage) failed — 25 jobs

Failure-reason breakdown across all 27 persistent failures (all_failures.json):

• 2 × job_execution_timeout — windows test_c: [7.2], windows test_c: [7.3]
• 25 × script_failure — System Tests: [..., tracer-release] across every PHP
  version (7.0–8.5) and SAPI (php-fpm, apache-mod, zts variants), all in the verify stage.

Crucially:

• The traces/ artifact directory is empty — the harness captures trace tails only
  for compilation/build failures, and there were none.
• There are no build-stage failures anywhere. The two failing stages are test
  (the Windows C-test timeout) and verify (System Tests). A real libdatadog API change
  (renamed symbol, changed signature, new required field, etc.) would surface as a Rust/C
  build failure in the tracer/appsec/profiler/shared builds — none occurred.
• The three sub-pipelines that exercise the libdatadog FFI most directly
  (shared, profiler, appsec) all passed, including their export paths.

I verified that every data-pipeline / trace_exporter definition touched by the
changelog lives under libdatadog/ (the C-ABI surface in libdd-data-pipeline-ffi);
dd-trace-php's own consumers of that ABI compiled cleanly, so the "move the async
boundary up" change preserved the FFI signatures we depend on.

Non-trivial changes made

No code changes required.

Identified libdatadog issues

None identified.

The data-pipeline change (#2064, "move the async boundary up") is an internal threading
refactor of trace submission. It did not break our build and the FFI consumers passed,
so there is nothing to work around. It is noted here only as the single behavioral change
in this update; if a future investigation links a System Tests regression to trace
flushing timing, this commit would be the first place to look — but the current evidence
does not support attributing the System Tests failures to it (see below).

Flaky / ignored failures

• windows test_c: [7.2] and [7.3] — job_execution_timeout. Both ran for ~3601s
  and hit the 1-hour job cap rather than failing a compile or assertion. This is a Windows
  runner timeout (infrastructure/flaky), unrelated to the libdatadog API. Ignored.

• 25 × System Tests: [..., tracer-release] — script_failure (verify stage). These
  run the separately-maintained DataDog system-tests harness against a fully built
  tracer-release package on a scheduled master pipeline. The package build itself
  succeeded (failures are in verify, not build), and the failures are uniform across
  all PHP versions and SAPIs, which is characteristic of a system-tests-harness/environment
  issue rather than version-specific tracer breakage. No system-test logs were downloaded
  into the artifacts (only job metadata), and there is no compilation impact, so these
  cannot be attributed to a libdatadog API change and require no code adaptation. Treated
  as unrelated/flaky. If they persist, they warrant a separate human look at the
  system-tests logs, independent of this libdatadog bump.

---

/cc @bwoebi

[datadog-prod-us1-6]

 

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 15 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-php | test_extension_ci: [7.1]     

🔧 Fix in code (Fix with Cursor).

4 failed tests due to leaked memory while running dynamic instrumentation tests.

DataDog/apm-reliability/dd-trace-php | test_extension_ci: [7.2]     

🔧 Fix in code (Fix with Cursor).

Assertion failed in zend_hash.c:712: Assertion `((ht)->gc.refcount == 1) || ((ht)->u.flags & (1<<6))' during dynamic instrumentation tests. Command terminated with exit code 2.

DataDog/apm-reliability/dd-trace-php | test_extension_ci: [7.3]     

🔧 Fix in code (Fix with Cursor).

Assertion failed in zend_hash.c:903: Assertion '(zend_gc_refcount(&(ht)->gc) == 1) || ((ht)->u.flags & (1<<6))' failed.

View all 15 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: 54.16% (+0.00%)

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 8e5b966 | Docs | Datadog PR Page | Give us feedback!}