libdatadog update to d7b2aad3

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	$LIBDATADOG_PINNED_SHA
New	d7b2aad37e2c45e44ba54473c9dd5ef5e3c94669

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

---

libdatadog Integration Report

libdatadog SHA: d7b2aad37e2c45e44ba54473c9dd5ef5e3c94669
Analysis date: 2026-07-04

Overall status

⚠️ Adapted (API changes fixed)

Build & test summary

All 176 failing jobs across every sub-pipeline (shared, appsec, package/windows)
trace back to a single root cause: the tracer's Rust crate datadog-php
(components-rs/) no longer compiles against the new libdatadog API. The compiler
reported exactly the same 4 errors in every failing build:

error[E0308] components-rs/remote_config.rs:646  tags:         expected Vec<String>, found Vec<Tag>
error[E0308] components-rs/remote_config.rs:647  process_tags: expected Vec<String>, found Vec<Tag>
error[E0616] components-rs/remote_config.rs:784  field `service` of struct `Target` is private
error[E0308] components-rs/stats.rs:151          is_trace_root: expected `Trilean`, found `bool`

How the 176 failures decompose (all downstream of the above compile failure):

• appsec integration / appsec extension / appsec coverage (~70 jobs) — the
  buildTracer-* Gradle/docker step compiles datadog-php and aborts. Confirmed
  directly in tmp/artifacts/traces/.
• compile extension windows (3 jobs) — same compile error (libdd_remote_config::Target).
• pecl tests (11 jobs) — build the extension, same failure.
• Extension Tea Tests (44 jobs) — the job runs make install first, which builds
  ddtrace.so (including components-rs + libdatadog Rust); it aborts before the
  pure-C tea tests run.
• Zend Abstract Interface Tests + ZAI Shared Tests (46 jobs) — the ZAI cmake test
  build (BUILD_ZAI_TESTING) includes components_rs.cmake, which runs cargo build
  in ../components-rs and links libdatadog_php.a, so it hits the same compile error.

There were no failures that were not explained by these three API changes, and
no failures originating from inside libdatadog itself.

Note: I cannot run cargo/make in this environment, so the fixes below are reasoned
from the compiler errors and the new libdatadog source; they were not locally compiled.

Non-trivial changes made

Three related, breaking libdatadog API changes were adapted. All edits are confined to
the tracer's own Rust (components-rs/); nothing under libdatadog/ was touched.

1. components-rs/remote_config.rs — libdd_remote_config::Target reworked

libdatadog #2182 (refactor(libdd-remote-config)!: hide Target inner properties) made
all Target fields private and added a Target::new(...) constructor. libdatadog
#2162 changed tags and process_tags from Vec<Tag> to Vec<String> (documented as
already-formatted "key:value" strings).

• Construction (ddog_remote_configs_service_env_change): replaced the struct
  literal Target { .. } with Target::new(..). The FFI still receives
  &libdd_common_ffi::Vec<Tag>, so each Tag is rendered to its "key:value" string
  via Tag's Display/to_string() before being collected into Vec<String>. (The
  struct-literal privacy errors did not appear in the CI trace only because type-checking
  aborted first; they would surface once the type errors are fixed, hence the switch to
  the constructor.)
• Reading the service (ddog_send_debugger_diagnostics, line 784): Target no
  longer exposes service and provides no accessor, so the previous
  t.service.as_str() has no direct replacement. Since our code is the sole place that
  constructs/tracks the target (track_target is only called from
  ddog_remote_configs_service_env_change, and the target is never reset in our code),
  I added a current_service: String field to RemoteConfigState, set it whenever we
  track a target, and read it for the debugger-diagnostics payload. The original
  semantics are preserved: an empty service is returned when no target is currently
  tracked (get_target().is_some() guard).

2. components-rs/stats.rs — FixedAggregationKey.is_trace_root: bool → pb::Trilean

libdatadog #2180 (chore!: update protobufs to be in sync with datadog-agent) changed
FixedAggregationKey::is_trace_root from bool to libdd_trace_protobuf::pb::Trilean
(NotSet / True / False). In build_fixed_key the PHP-supplied bool is now
mapped to Trilean::True / Trilean::False (mirroring libdatadog's own
aggregation.rs). The PHP side always knows whether a span is a trace root, so
NotSet is never emitted.

3. components-rs/Cargo.toml — new dependency

Trilean lives in libdd-trace-protobuf, which was only a transitive dependency (via
libdd-trace-stats, which does not re-export it). Added a direct path dependency:

libdd-trace-protobuf = { path = "../libdatadog/libdd-trace-protobuf" }

libdd-trace-protobuf is already part of the workspace / lockfile (used by
libdd-trace-stats), and the extension build does not use --locked/--frozen, so this
adds a resolver edge without introducing a version conflict.

Identified libdatadog issues

None identified. All failures were plain, expected API-compatibility breaks (the
libdatadog commits are explicitly marked breaking with !), each with a clear new API to
adapt to.

One thing worth flagging to the libdatadog team (not a bug, but a rough edge): #2182 hid
Target::service without providing a public getter, so consumers that legitimately need
to read back the target's service (as the PHP debugger-diagnostics path did) must now
track it themselves. A Target::service(&self) -> &str accessor would be a friendlier
API. Our workaround is clean and does not depend on the hidden field.

Flaky / ignored failures

None. Every one of the 176 failures is explained by the single components-rs compile
failure and is expected to clear once the adaptations above are built.

---

/cc @bwoebi

[datadog-prod-us1-3]

 

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 114 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-php | ASAN test_c: [8.0, arm64]     

🧪 7 Tests failed

All test failures are known flaky.

❄️ Known flaky: tmp/build_extension/tests/ext/appsec/sca_flag_is_sent_01.phpt (DD_APPSEC_SCA_ENABLED flag is sent to via telemetry with default value) from PHP.tmp.build_extension.tests.ext.appsec  

002+ bool(false)
001- array(5) {
002-   ["name"]=>
003-   string(21) "DD_APPSEC_SCA_ENABLED"
004-   ["value"]=>
005-   string(5) "false"
006-   ["origin"]=>
007-   string(7) "default"
008-   ["config_id"]=>
009-   NULL
...

Not introduced in this PR.

❄️ Known flaky: tmp/build_extension/tests/ext/appsec/sca_flag_is_sent_02.phpt (DD_APPSEC_SCA_ENABLED flag is sent to via telemetry with true) from PHP.tmp.build_extension.tests.ext.appsec  

002+ bool(false)
001- array(5) {
002-   ["name"]=>
003-   string(21) "DD_APPSEC_SCA_ENABLED"
004-   ["value"]=>
005-   string(4) "true"
006-   ["origin"]=>
007-   string(7) "env_var"
008-   ["config_id"]=>
009-   NULL
...

Not introduced in this PR.

View all failed tests

DataDog/apm-reliability/dd-trace-php | ASAN test_c: [8.4, arm64]     

🧪 13 Tests failed

All test failures are known flaky.

❄️ Known flaky: tmp/build_extension/tests/ext/appsec/sca_flag_is_sent_01.phpt (DD_APPSEC_SCA_ENABLED flag is sent to via telemetry with default value) from php.tmp.build_extension.tests.ext.appsec  

001- array(5) {
002-   ["name"]=>
003-   string(21) "DD_APPSEC_SCA_ENABLED"
004-   ["value"]=>
005-   string(5) "false"
006-   ["origin"]=>
007-   string(7) "default"
008-   ["config_id"]=>
009-   NULL
010-   ["seq_id"]=>
...

Not introduced in this PR.

❄️ Known flaky: tmp/build_extension/tests/ext/appsec/sca_flag_is_sent_02.phpt (DD_APPSEC_SCA_ENABLED flag is sent to via telemetry with true) from php.tmp.build_extension.tests.ext.appsec  

001- array(5) {
002-   ["name"]=>
003-   string(21) "DD_APPSEC_SCA_ENABLED"
004-   ["value"]=>
005-   string(4) "true"
006-   ["origin"]=>
007-   string(7) "env_var"
008-   ["config_id"]=>
009-   NULL
010-   ["seq_id"]=>
...

Not introduced in this PR.

View all failed tests

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

View all 114 failed jobs.

ℹ️ Info

No other issues found (see more)

❄️ No new flaky tests detected

🔄 Datadog auto-retried 8 jobs - 0 passed on retry

🎯 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: a465743 | 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 👍 / 👎.

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2026-07-04 05:31:27

Comparing candidate commit a465743 in PR branch bot/libdatadog-latest with baseline commit 0c09f3c in branch master.

Found 0 performance improvements and 8 performance regressions! Performance is the same for 185 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-opcache

• 🟥 execution_time [+4.050µs; +5.750µs] or [+3.841%; +5.452%]

scenario:SamplingRuleMatchingBench/benchRegexMatching1

• 🟥 execution_time [+33.262ns; +107.138ns] or [+2.241%; +7.219%]

scenario:SamplingRuleMatchingBench/benchRegexMatching2

• 🟥 execution_time [+58.931ns; +129.669ns] or [+3.999%; +8.798%]

scenario:SamplingRuleMatchingBench/benchRegexMatching2-opcache

• 🟥 execution_time [+546.313ns; +960.887ns] or [+3.209%; +5.645%]

scenario:SamplingRuleMatchingBench/benchRegexMatching3-opcache

• 🟥 execution_time [+522.156ns; +848.644ns] or [+3.043%; +4.945%]

scenario:SamplingRuleMatchingBench/benchRegexMatching4

• 🟥 execution_time [+33.381ns; +101.219ns] or [+2.228%; +6.755%]

scenario:SamplingRuleMatchingBench/benchRegexMatching4-opcache

• 🟥 execution_time [+516.557ns; +870.443ns] or [+3.008%; +5.070%]

scenario:TraceSerializationBench/benchSerializeTrace-opcache

• 🟥 execution_time [+52.436µs; +86.364µs] or [+2.569%; +4.232%]