libdatadog update to 24680da3

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	$LIBDATADOG_PINNED_SHA
New	24680da3827160070786f97173b44ded23b39d75

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

---

libdatadog Integration Report

libdatadog SHA: 24680da3827160070786f97173b44ded23b39d75
Analysis date: 2026-10-06

Overall status

⚠️ Adapted (API changes fixed)

The cargo-related failures have one root cause, and it is now fixed in
Cargo.toml. One group of failures (ZAI tests, 46 jobs) has no log artifacts
and cannot be explained by this libdatadog update. It needs a manual look; see
below.

Build & test summary

143 persistent failures across sub-pipelines (tracer, profiler, appsec,
package, shared). Every failure trace in tmp/artifacts/traces/ (appsec
integration tests, helper-rust build/test, profiling tests) stops at the same
cargo manifest-resolution error, before any Rust code is compiled:

error: failed to load manifest for dependency `libdd-library-config-ffi`
  failed to parse manifest at `libdatadog/libdd-library-config-ffi/Cargo.toml`
  error inheriting `libc_alloc` from workspace root manifest's
  `workspace.dependencies.libc_alloc`
  `dependency.libc_alloc` was not found in `workspace.dependencies`

Root cause: libdatadog crates (edition.workspace, foo.workspace = true)
are built as path dependencies of our root workspace. They inherit from
dd-trace-php's [workspace.dependencies], which mirrors libdatadog's copy by
hand. libdatadog commit 7717de8e3 (feat(library-config)!: make libdd-library-config no_std compatible, #1770) added two workspace
dependencies, libc_alloc and yaml_serde (the replacement for
serde_yaml). Our mirror didn't have them.

Since cargo fails while it parses the manifests, every job that runs cargo on
this workspace fails the same way:

• profiler: Cargo test, Clippy, profiling tests, PHP language tests
• appsec: helper-rust build/test/coverage, appsec integration tests (+ SSI)
• package: pecl tests, the system-tests docker image

That error was hiding everything after it, so I also checked the five
libdatadog commits since the previous pin (70e7c0bc5) for API breaks that
would show up once the manifest resolves (details below).

Non-trivial changes made

Cargo.toml

1. [workspace.dependencies] synced with libdatadog/Cargo.toml:

   • added libc_alloc = { version = "1.0", default-features = false }
     (used by libdd-library-config-ffi's optional standalone feature;
     cargo still has to resolve it)
   • added yaml_serde = { version = "0.10.7", default-features = false }
     (a required dependency of libdd-library-config)
   • removed kernel32-sys and winapi, which libdatadog dropped from its
     list. No crate in our workspace inherits them.

   A sorted diff of the dependency names in the two
   [workspace.dependencies] tables now comes back empty.

2. libdd-common-ffi now requests features = ["std"]. In Collect client ip only when customer indicates to do so #1770,
   libdd-common-ffi became no_std unless the new std feature (on by
   default) is enabled. Without it, Error, Handle, Option, Result,
   MutSlice, string::*, timespec::* and their deps are compiled out. We
   use default-features = false and re-export libdd_common_ffi::* from
   components-rs/lib.rs, so we need std. Every libdatadog FFI crate was
   updated the same way (default-features = false, features = ["std"]).
   Feature unification through e.g. datadog-sidecar-ffi would probably turn
   it on anyway, but we shouldn't rely on that.

3. libdd-library-config-ffi now requests features = ["std"]. This one
   is required. The same commit moved ddog_library_configurator_get,
   ddog_library_configurator_with_detect_process_info,
   ddog_library_config_source_to_string,
   ddog_library_config_{fleet,local}_stable_config_path and
   ddog_library_config_drop into a #[cfg(feature = "std")] mod std_api
   (libdatadog/libdd-library-config-ffi/src/lib.rs:159). std is a default
   feature, but we disable defaults and nothing else in the graph enables
   libdd-library-config-ffi/std. Without this change those symbols would
   silently disappear from the build, and the C code that calls them
   (zend_abstract_interface/config/config_stable_file.c, profiler bindings)
   would break at link or load time.

Other checks (no change needed)

• ABI of the library-config FFI: the signatures of every
  ddog_library_* function, and of the LibraryConfig and ProcessInfo
  structs, are the same as at 70e7c0bc5. The checked-in
  components-rs/library-config.h is still valid.
• libdd-library-config direct dependency (otel-thread-ctx,
  process-context-reader): both features now imply std, so
  otel_process_ctx, tracer_metadata and ProcessContextSelfReader (used
  by components-rs/lib.rs and profiling/src/process_context/linux.rs) are
  still exported.
• Skip the flaky unix socket test on CI environments #2535 (StatsComputationObfuscationConfig.sql_obfuscation_mode →
  obfuscation_config: SqlConfig, AgentObfuscationConfig.sql_obfuscation_mode
  is now an Option): we don't reference these. components-rs only uses
  AgentInfoStruct and FixedAggregationKey, which didn't change.
• build(profiling): update to libdatadog v7 #2605, Add libdatadog-apm as codeowners. #2632, style(profiling): fix some easy clippy lints #2633 (FFE privacy, tracer top-level markings,
  crashtracking upload priority): additive or internal only.
• Cargo.lock is tracked, but CI doesn't build with --locked, so cargo
  adds yaml_serde and libc_alloc to the lockfile on the next build. I
  couldn't regenerate it here because no Rust toolchain is available.

Not verified: I couldn't run cargo in this environment, so these changes
are reasoned from the error messages and the libdatadog sources. The next CI
run is the real check.

Identified libdatadog issues

None identified. Requiring consumers to mirror [workspace.dependencies] by
hand is a known cost of building libdatadog crates as members of our
workspace, not a libdatadog bug.

Flaky / ignored failures

• Zend Abstract Interface Tests (44 jobs) and ZAI Shared Tests (2 jobs),
  [shared-trigger]: unexplained, need manual inspection. No traces were
  collected for these jobs (all just report script_failure). The ZAI build
  (.gitlab/generate-shared.php, zend_abstract_interface/CMakeLists.txt)
  runs CMake only and never invokes cargo. config_stable_file.c resolves the
  ddog_library_* symbols at runtime via function pointers, and uses the
  checked-in components-rs/library-config.h, which this update doesn't
  change. So the manifest error above cannot be their cause, and I have no
  evidence that ties them to the libdatadog update. They were not failing on
  the previous automated update (that pipeline reported 1 failed job). Check
  the job logs in pipeline 142939162. Possible causes are an infrastructure
  problem or a failing upstream Build & Test Tea artifact.

---

/cc @bwoebi

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-06T05:12:38.322906Z	34ce24a	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[datadog-prod-us1-3]

 

❌ Errors

Your PR has failed checks. Please review the issues below and take necessary action before merging.

🚦 3 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-php | test early PHP 8.1 — 🔄 Retry may pass, looks flaky

View more details · View in GitLab

DataDog/apm-reliability/dd-trace-php | merge-gate

View more details · View in GitLab

DataDog/apm-reliability/dd-trace-php | publish docker image for system tests

View more details · View in GitLab

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 68.57% (+0.00%)

Useful? React with 👍 / 👎

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

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2026-10-07 19:18:49

Comparing candidate commit ef104aa in PR branch bot/libdatadog-latest with baseline commit 240aae9 in branch master.

📊 Benchmarking dashboard

Found 1 performance improvements and 0 performance regressions! Performance is the same for 192 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:SamplingRuleMatchingBench/benchRegexMatching1

• 🟩 execution_time [-96.849ns; -34.751ns] or [-6.488%; -2.328%]

Unstable benchmarks

These benchmarks have a confidence interval too wide to call a change; treat them as noise rather than signal.

scenario:LaravelBench/benchLaravelDdprof-opcache

• unstable execution_time [-925.861µs; +479.661µs] or [-6.957%; +3.604%]