libdatadog update to 4678752b

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	$LIBDATADOG_PINNED_SHA
New	4678752b4be5bec7e55112598eb1b9491ddd9cc6

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

---

libdatadog Integration Report

libdatadog SHA: 4678752b4be5bec7e55112598eb1b9491ddd9cc6
Analysis date: 2026-08-17

Overall status

⚠️ Adapted (API changes fixed)

Build & test summary

The pipeline reported 174 persistent job failures spread over three
sub-pipelines:

Sub-pipeline	iid	Status	Failed jobs collected
profiler-trigger	85748	✅ success	0
appsec-trigger	85749	❌ failed	72
shared-trigger	85750	❌ failed	90
package-trigger	85751	❌ failed	12
tracer-trigger	85752	❌ failed	0 (not collected — see note)

Every one of the 174 failures has the same single root cause: the
datadog-php crate (components-rs/) failed to compile with 9 errors, all in
components-rs/remote_config.rs. All 71 collected trace files contain exactly
the same error block, and the remaining failures are jobs that build the
extension (and therefore components-rs) without a collected trace:

• shared-trigger — Zend Abstract Interface Tests and ZAI Shared Tests
  build components-rs too: zend_abstract_interface/CMakeLists.txt:21
  includes components_rs.cmake when BUILD_ZAI_TESTING=ON, and
  catch2_main links the resulting libdatadog_php.a. Extension Tea Tests
  run make install, which builds ddtrace.so.
• appsec-trigger — helper-rust integration coverage runs the appsec
  integration suite (./gradlew test8.3-debug), which builds the extension.
• package-trigger — pecl tests and publish docker image for system tests
  build the extension from source.

The profiler sub-pipeline passed, which is consistent: profiling/ does not
use libdd-remote-config.

The 9 compile errors were:

error[E0063]: missing field `agentless` in initializer of `ConfigInvariants`   (:217)
error[E0609]: no field `product` on type `RemoteConfigValue`                   (:392)
error[E0609]: no field `config_id` on type `RemoteConfigValue`             (:396,397,419)
error[E0616]: field `product` of struct `RemoteConfigPath` is private          (:441)
error[E0615]: attempted to take value of method `config_id` on `RemoteConfigPath` (:443,450)
error[E0609]: no field `config_id` on type `RemoteConfigPath`                  (:445)

All are straightforward API adaptations (see below). No behavioural test
failures were observed anywhere — nothing got far enough to run.

Note: because compilation aborts at type-checking, borrow-checking never ran on
this file. The edits were made to preserve the existing borrow structure (the
new &str accessors borrow from value/path, which are locals unrelated to
remote_config), but I could not verify this by building — there is no Rust
toolchain in this environment.

Note on the tracer sub-pipeline: bridge tracer-trigger (pipeline 85752) is
failed, but none of its jobs appear in tmp/artifacts/all_failures.json
(which only covers 85749/85750/85751). That looks like a gap in the artifact
collection rather than a distinct problem — the tracer builds
components-rs/remote_config.rs as well, so the same compile error applies.

Non-trivial changes made

components-rs/remote_config.rs

Three related upstream API changes, from
20a3f4d67 feat(remote-config)!: agentless RC fetcher (#2112) and the
RemoteConfigPath rework (ea75b04c3, 44f705ff1):

1. ConfigInvariants gained a required agentless field
   (libdatadog/libdd-remote-config/src/fetch/fetcher.rs:54-64). It is
   Option<agentless::AgentlessConfig> with the agentless feature and
   Option<std::convert::Infallible> without it; we do not enable that
   feature, and the PHP tracer fetches remote config through the local Agent,
   so the correct value is None — which type-checks under either cfg branch.
   Added agentless: None to the initializer in
   ddog_init_remote_config_state.

2. RemoteConfigValue no longer carries product/config_id — it is now
   { path: RemoteConfigPath, data: Option<RemoteConfigParsed> }
   (libdatadog/libdd-remote-config/src/parse.rs:187-190), with the
   product/config-id/name components read back off the path. Updated:

   • value.product → value.path.product()
   • value.config_id → value.path.config_id()

3. RemoteConfigPath fields are now private, exposed via accessors
   (libdatadog/libdd-remote-config/src/path.rs:103-143). The path is stored
   as a single Box<str> plus offsets, so config_id() returns a borrowed
   &str instead of an owned String. Updated:

   • path.product → path.product()
   • path.config_id → path.config_id()

   Ownership consequences handled at the three sites that needed an owned key:

   • live_debugger.active.entry(value.config_id) →
     entry(config_id.to_string()), where
     let config_id = value.path.config_id(); replaces the previous
     value.config_id.clone(). apply_config already takes &str, so the
     extra String that used to be cloned for it is gone.
   • dynamic_config.active_configs.insert(value.config_id, …) →
     insert(value.path.config_id().to_string(), …).
   • The two remove(&path.config_id) calls became remove(path.config_id())
     — both maps are keyed by String, and String: Borrow<str>, so looking
     up by &str is valid and avoids an allocation.

No other file needed changes: ConfigInvariants and RemoteConfigPath are
only used opaquely elsewhere (components-rs/common.h,
components-rs/sidecar.h, appsec/src/helper/runner.cpp), and
appsec/helper-rust's config_id/product fields belong to its own
independent path-parsing struct (appsec/helper-rust/src/rc.rs:360), not to
libdatadog's.

The match on value.path.product() and on path.product() both keep their
existing _ => {} catch-all arms, so the new DEBUG RC product added in
7be7ac7f3 chore(rc)!: add DEBUG product (#2306) needs no further handling
here.

Identified libdatadog issues

None identified. Every failure traced back to a deliberate, well-signposted
breaking API change (all the relevant upstream commits are marked !), and
each had an obvious replacement API in the new tree.

Flaky / ignored failures

None. All 174 failures share the single compilation root cause described
above; nothing was dismissed as flaky.

Worth flagging for the CI tooling rather than for libdatadog: the
tracer-trigger sub-pipeline (85752) failed but contributed zero jobs to
all_failures.json, so the "174" count understates the real fallout.

---

/cc @bwoebi

[datadog-datadog-prod-us1-2]

 

✨ Unblock PR with BitsAI

⚠️ Warnings

🚦 18 Pipeline jobs failed

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

View in Datadog · View in GitLab

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

View in Datadog · View in GitLab

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

View in Datadog · View in GitLab

View all 18 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.00%)

Useful? React with 👍 / 👎

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

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2026-08-18 16:50:36

Comparing candidate commit e42db98 in PR branch bot/libdatadog-latest with baseline commit 34bb400 in branch master.

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

• 🟩 execution_time [-4.856µs; -2.464µs] or [-4.602%; -2.335%]

scenario:PHPRedisBench/benchRedisOverhead

• 🟥 execution_time [+51.561µs; +65.939µs] or [+5.018%; +6.418%]

scenario:SpanBench/benchDatadogAPI

• 🟥 execution_time [+2.006µs; +3.285µs] or [+2.913%; +4.772%]

scenario:TraceSerializationBench/benchSerializeTrace

• 🟩 execution_time [-24.788µs; -9.712µs] or [-5.549%; -2.174%]