libdatadog update to 4b79b7ed

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	$LIBDATADOG_PINNED_SHA
New	4b79b7ed87113bea01db583d54e13fb0c2a19e74

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

---

libdatadog Integration Report

libdatadog SHA: 4b79b7ed87113bea01db583d54e13fb0c2a19e74
Analysis date: 2026-06-25

Overall status

✅ Clean update (no API changes required) — the two failures are Windows-only test
job timeouts, not compilation/API incompatibilities.

Build & test summary

Across all sub-pipelines (tracer, appsec, profiler, shared, package) only 2 jobs
failed, both in the tracer pipeline:

• windows test_c: [7.3]
• windows test_c: [7.2]

Both failed with failure_reason: "job_execution_timeout", each running for ~3603s
(the 60-minute GitLab default wall-clock limit) before being killed. Both jobs had
already been auto-retried (see retried_jobs.tsv) and timed out again.

Crucially, no compilation failures were reported anywhere:

• The traces/ artifact directory is empty (trace tails are only captured for
  compilation/build failures; none occurred).
• The windows test_c job builds the extension inside the job via
  phpize / configure / nmake (.gitlab/generate-tracer.php:139) and only then runs
  the PHP test suite (:145). A build incompatibility against the new libdatadog
  headers/FFI would surface as a script_failure during nmake, not as a
  job_execution_timeout. The build succeeded; the job hung during test execution.
• All other jobs that link against libdatadog (Linux compile jobs, ASAN, appsec,
  profiler, shared, package) passed. If any of the breaking (!) changes in this
  libdatadog batch had broken our Rust/FFI call sites, those compile jobs would have
  failed too. They did not.

Conclusion: the new libdatadog (4b79b7ed) is API-compatible with dd-trace-php. The two
failures are a Windows-only runtime timeout/flake, not an API change.

Non-trivial changes made

No code changes required. The update is API-compatible; a job-execution timeout cannot
be addressed by editing Rust call sites, and there is no API surface that changed in a
way that requires adaptation.

Identified libdatadog issues

None identified with certainty.

For completeness: a consistent hang on both PHP versions (surviving retry) is worth
keeping an eye on. If these Windows test_c timeouts persist across subsequent
libdatadog bumps, the runtime-affecting changes in this batch are the candidates to
investigate as a possible libdatadog-side Windows hang (these are NOT being worked
around — they would be libdatadog runtime bugs, not API adaptations):

• 4b79b7ed8 feat(shared-runtime)!: SharedRuntime Borrowed & Owned mode (#2061) (HEAD)
• da8cbcb8b feat(shared-runtime)!: use weak waker in trigger (#2050)
• b10b1d465 chore(profiling): Use SECURITY_ANONYMOUS when connecting to named pipe server (#2134) (Windows named pipe)
• sidecar changes: bf2ae0f74 (Add automated login events to symfony 4.4 and 6.2 #2146), 03357ee13 oneshot flusher (update CI parametric tests #2143), aceec12b1 retry interval ([BUG] Multiple unique TypeError's are being grouped as the same and have the same fingerprint #2106)

However, there is no log evidence (no captured trace) pointing at any of these, and the
build succeeded, so this is not actionable today.

Flaky / ignored failures

• windows test_c: [7.3] and windows test_c: [7.2] — both job_execution_timeout
  (~60m wall clock), already auto-retried. Classified as flaky / infrastructure timeout.

  The windows test_c job has a long, documented history of timeouts and deadlocks
  independent of libdatadog, e.g.:

  • 6ea66b266 fix(ci): exclude hook_does_not_leak_error from windows test_c (php-cgi stderr deadlock)
  • 93187d9f2 ci: fix Windows job flakiness caused by dirty workspace (#3694)
  • 4663b2fa7 Fix: add cleanup for windows test_c (#3401)

  Combined with the absence of any compilation/API failure, the right classification
  per the rules (timing / timeout) is flaky/infrastructure. No code change is warranted.

---

/cc @bwoebi

[datadog-prod-us1-3]

 

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 6 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-php | ASAN test_c with multiple observers: [8.3]     

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

Profiling correctness | prof-correctness (8.4, zts)     

View all 6 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.08% (-0.03%)

Useful? React with 👍 / 👎

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 91b5f2bade

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Regenerate Cargo.lock for the new libdatadog versions

This bump points at a libdatadog revision that changes path package versions (libdd-common 4.2.0→5.0.0 and libdd-remote-config 0.1.0→1.0.0), but the parent Cargo.lock is unchanged and still records the old versions. I checked cargo build --help; --locked asserts the lockfile remains unchanged, so locked/reproducible builds from this commit will fail before compilation because Cargo must rewrite the lockfile for those path dependencies. Please regenerate and commit Cargo.lock with this submodule revision.

Useful? React with 👍 / 👎.