libdatadog update to f9ac7f2b

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	$LIBDATADOG_PINNED_SHA
New	f9ac7f2bbac1488791f88df2a78177f608c33633

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

---

libdatadog Integration Report

libdatadog SHA: f9ac7f2bbac1488791f88df2a78177f608c33633
Analysis date: 2026-07-08

Overall status

⚠️ Adapted (API changes fixed)

Build & test summary

CI reported 177 failed jobs. All of them (across the tracer, appsec, and package
sub-pipelines) trace back to a single root cause: the Rust crate datadog-php
(components-rs/) no longer compiled against the new libdatadog, failing with the
same 4 errors in every job:

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

Because the extension (ddtrace.so) could not be built, every downstream job that
compiles or links it failed:

• tracer-trigger: compile extension: debug-zts-asan — direct compile failure.
• package-trigger: compile tracing extension asan, compile extension windows,
  and all pecl tests — depend on building the extension.
• appsec-trigger: all appsec integration tests, test appsec extension,
  helper-rust integration coverage, appsec code coverage — build the tracer as a
  dependency (buildTracer-* gradle task fails with the same rustc errors).

After the fixes below, the datadog-php crate compiles again, which unblocks all of
those cascading jobs.

The ~90 shared-trigger failures (Extension Tea Tests, Zend Abstract Interface Tests, ZAI Shared Tests) are not caused by this update — see "Flaky / ignored".

Non-trivial changes made

components-rs/stats.rs — FixedAggregationKey::is_trace_root is now pb::Trilean

libdatadog synced its protobufs with the agent (chore!: update protobufs to be in sync with datadog-agent, #2180). FixedAggregationKey.is_trace_root changed from
bool to libdd_trace_protobuf::pb::Trilean (an unset/true/false tristate).

• Added use libdd_trace_protobuf::pb;.
• In build_fixed_key, converted the PHP-side bool to the tristate, matching
  libdatadog's own internal conversion (aggregation.rs):

  is_trace_root: if span.is_trace_root { pb::Trilean::True } else { pb::Trilean::False },

• The other reference (stats.rs:496, copying fixed.is_trace_root into
  OwnedShmSpanInput) needed no change — it is now Trilean→Trilean, which is why
  CI only flagged line 151.

components-rs/Cargo.toml — new dependency

Added libdd-trace-protobuf = { path = "../libdatadog/libdd-trace-protobuf" } so the
crate can name the pb::Trilean type. It is a path dependency to the same vendored
crate libdd-trace-stats already uses, so pb::Trilean resolves to the identical type.

components-rs/remote_config.rs — Target is now opaque; tags are Vec<String>

Two libdatadog changes intersect here:

• refactor(libdd-remote-config)!: hide Target inner properties so they are not leaked
  (fix: lifetime issue cached filename #2182) made all Target fields private and removed field access; the only public
  constructor is Target::new(service, env, app_version, tags, process_tags).
• The tags / process_tags fields changed type from Vec<Tag> to Vec<String>
  (already-formatted "key:value" strings, per Target::new's doc comment).

Changes:

1. ddog_remote_configs_service_env_change: build the target via Target::new(...)
   instead of a struct literal, and convert the incoming Vec<Tag> to
   Vec<String> with tags.as_slice().iter().map(ToString::to_string).collect()
   (Tag's Display yields the full "key:value" string).

2. Because Target no longer exposes service, and ddog_send_debugger_diagnostics
   needs the service string, RemoteConfigState now keeps its own copy
   (target_service: String), set at the single track_target call site (the only
   place a Target is ever tracked on this manager). ddog_send_debugger_diagnostics
   reads that copy instead of get_target().service.

   This is behavior-preserving: track_target is the only mutator of the manager's
   active target in our code (no reset_target/reset calls), so before the first
   service_env_change the stored value is "" — exactly what the previous
   get_target().map_or("", …) returned — and afterwards the two stay in lock-step.

   RemoteConfigState is an opaque type on the C side (not #[repr(C)]; only ever
   handled via Box/pointer), so adding a private field does not affect the C ABI or
   require regenerating datadog.h.

Identified libdatadog issues

None identified. All four errors are legitimate, expected breaking-change adaptations
(the corresponding commits are marked ! in the changelog). Note, however, a minor
ergonomic gap: #2182 hid Target's fields without providing read accessors
(e.g. a service() getter), which forced consumers that still need the service name
to track their own copy. Not a bug, but a getter would have made the migration
cheaper for downstream libraries.

Flaky / ignored failures

• shared-trigger jobs (~90): Extension Tea Tests, Zend Abstract Interface Tests, and ZAI Shared Tests across all PHP versions. These build the standalone
  tea test framework and the zend_abstract_interface component, neither of which
  links the libdatadog Rust code. They produced no compilation traces (the harness
  only captures traces for compile/build failures), so they are not caused by the Rust
  API change. Left as-is as unrelated / pre-existing infrastructure failures.

---

/cc @bwoebi

[datadog-prod-us1-3]

 

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 1628 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-php | appsec integration tests: [test7.4-release]     

🧪 20 Tests failed

[1] file_get_contents, 19 from com.datadog.appsec.php.integration.Apache2FpmTests  

Assertion failed: 

assert re.statusCode() == 200
       |  |            |
       |  503          false
       (GET http://docker:32770/ssrf.php?function=file_get_contents&domain=169.254.169.254) 503

Assertion failed: 

assert re.statusCode() == 200
...

[1] file_put_contents, /tmp/dummy, 9 from com.datadog.appsec.php.integration.Apache2FpmTests  

Assertion failed: 

assert re.statusCode() == 200
       |  |            |
       |  503          false
       (GET http://docker:32770/filesystem.php?function=file_put_contents&path=/tmp/dummy) 503

Assertion failed: 

assert re.statusCode() == 200
...

View all failed tests

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

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

View all 1628 failed jobs.

ℹ️ Info

No other issues found (see more)

❄️ No new flaky tests detected

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

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 0318611 | 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-07 06:03:36

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

Found 0 performance improvements and 2 performance regressions! Performance is the same for 192 metrics, 0 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 [+2.888µs; +3.652µs] or [+2.752%; +3.481%]

scenario:MessagePackSerializationBench/benchMessagePackSerialization-opcache

• 🟥 execution_time [+4.593µs; +6.247µs] or [+4.337%; +5.899%]