libdatadog update to d7980db6

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	$LIBDATADOG_PINNED_SHA
New	d7980db6be51fe821f4547512bc51d67654b99a9

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

---

libdatadog Integration Report

libdatadog SHA: d7980db6be51fe821f4547512bc51d67654b99a9
Analysis date: 2026-07-17

Overall status

⚠️ Adapted (API changes fixed)

Build & test summary

All 176 failing jobs share a single root cause: the datadog-php crate
(components-rs/) no longer compiled against the new libdatadog, so every job
that builds the ddtrace extension failed downstream.

The failing job families were:

Family	Count	Why it failed
Extension Tea Tests	44	build the extension (links datadog-php)
Zend Abstract Interface Tests	44	build the extension
test appsec extension	44	build the extension
appsec integration tests (+ helper-cpp/ssi)	26	buildTracer-* compiles datadog-php
pecl tests	11	build the extension
compile extension windows	3	compiles datadog-php
ZAI Shared Tests	2	build the extension
appsec code coverage	1	compiles datadog-php (tracer-release)
helper-rust integration coverage	1	builds the extension

Every captured compilation trace (appsec_*, compile_extension_windows:*)
ends with the same 4 rustc errors, all in components-rs/:

error[E0308] remote_config.rs:657  tags:         expected Vec<String>, found Vec<Tag>
error[E0308] remote_config.rs:658  process_tags: expected Vec<String>, found Vec<Tag>
error[E0616] remote_config.rs:801  field `service` of struct `Target` is private
error[E0308] stats.rs:151          is_trace_root: expected Trilean, found bool
error: could not compile `datadog-php` (lib) due to 4 previous errors

No test-level or non-compilation failures were present. Once datadog-php
compiles, all downstream C/PHP/appsec tests should build and run again.

Non-trivial changes made

1. components-rs/remote_config.rs — Target API change

libdatadog made Target's fields private and changed the tag field types.
The struct is now:

pub struct Target {
    service: String,
    env: String,
    app_version: String,
    tags: Vec<String>,         // was Vec<Tag>
    process_tags: Vec<String>, // was Vec<Tag>
}

with a public constructor Target::new(...) and getters service(), env(),
app_version() (libdatadog commits eaf5ad066 "hide Target inner properties"
and 85ce322a1 "Make Target fields available again").

• ddog_remote_configs_service_env_change: replaced the direct struct literal
  (which used private fields and passed Vec<Tag>) with Target::new(...).
  The incoming &libdd_common_ffi::Vec<Tag> is converted to the
  Vec<String> of "key:value" strings that Target::new documents it
  expects, via .iter().map(|t| t.to_string()).collect(). This is
  content-preserving: a Tag stores its whole "key:value" string in a
  single field and its Display/to_string() emits it verbatim, so the new
  Vec<String> holds exactly what the old Vec<Tag> did.
• ddog_send_debugger_diagnostics: t.service.as_str() → t.service()
  (the getter, matching the now-private field).

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

The protobuf sync (b02d45457 "update protobufs to be in sync with
datadog-agent") changed ClientGroupedStats.is_trace_root — and consequently
FixedAggregationKey::is_trace_root in libdd-trace-stats — from bool to
the tri-state pb::Trilean enum (NotSet/True/False).

• Added use libdd_trace_protobuf::pb::Trilean;.
• build_fixed_key: is_trace_root: span.is_trace_root (a PHP-supplied
  bool) → if span.is_trace_root { Trilean::True } else { Trilean::False }.
  There is no From<bool> impl for Trilean in libdatadog, so the mapping is
  written explicitly, mirroring libdatadog's own conversion in
  aggregation.rs. Our FFI input struct PhpSpanStats.is_trace_root stays a
  bool; only the value handed to libdatadog is converted.

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

Trilean lives in libdd-trace-protobuf, which was not a direct dependency of
datadog-php (only reachable transitively through libdd-trace-stats). Added
the path dependency so the type can be named:

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

Identified libdatadog issues

None identified. All four breakages are intentional, breaking (!) API
refactors on the libdatadog side, each with a clear replacement API. No panics,
regressions, or missing-functionality problems were observed.

Flaky / ignored failures

None. Every failing job traces to the single datadog-php compilation break;
there were no timing/flaky failures and no failures unrelated to the libdatadog
update.

---

/cc @bwoebi

[datadog-prod-us1-3]

 

✨ Unblock PR with BitsAI

⚠️ Warnings

🚦 1622 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-php | appsec integration tests: [test8.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 1622 failed jobs.

ℹ️ Info

No other issues found (see more)

❄️ No new flaky tests detected

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

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: e7abeb7 | 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-12 07:35:42

Comparing candidate commit c75dcc1 in PR branch bot/libdatadog-latest with baseline commit 992399d in branch master.

Found 0 performance improvements and 5 performance regressions! Performance is the same for 189 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.926µs; +3.854µs] or [+2.726%; +3.591%]

scenario:MessagePackSerializationBench/benchMessagePackSerialization-opcache

• 🟥 execution_time [+4.358µs; +5.242µs] or [+4.105%; +4.938%]

scenario:SamplingRuleMatchingBench/benchRegexMatching1

• 🟥 execution_time [+32.529ns; +97.871ns] or [+2.192%; +6.596%]

scenario:SamplingRuleMatchingBench/benchRegexMatching3

• 🟥 execution_time [+37.437ns; +103.163ns] or [+2.515%; +6.930%]

scenario:SamplingRuleMatchingBench/benchRegexMatching4

• 🟥 execution_time [+101.074ns; +176.126ns] or [+6.912%; +12.044%]