libdatadog update to fb65e461

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	$LIBDATADOG_PINNED_SHA
New	fb65e461614fb9819c50d1cdc1337ca9605458da

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

---

libdatadog Integration Report

libdatadog SHA: fb65e461614fb9819c50d1cdc1337ca9605458da
Analysis date: 2026-07-20

Overall status

⚠️ Adapted (API changes fixed)

Build & test summary

All 176 failing jobs across the shared, appsec, and package sub-pipelines
share a single root cause: the datadog-php crate (components-rs/) no
longer compiles against the new libdatadog, producing exactly 4 Rust compiler
errors:

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

Every failing job builds the ddtrace extension (which statically links
libdatadog_php.a), so the extension build fails before any test runs:

• [shared-trigger] Extension Tea Tests (44) + Zend Abstract Interface /
  ZAI Shared Tests (46) — C tests that link the extension.
• [appsec-trigger] appsec integration tests, test appsec extension,
  helper-cpp/ssi variants, code coverage, helper-rust integration coverage (84)
  — all run the buildTracer-* Gradle task, which compiles components-rs.
• [package-trigger] pecl tests (11) + compile extension windows (3).

I confirmed via tmp/artifacts/traces/ and tmp/artifacts/all_failures.json
that no failing job exhibits any error signature other than these four; no
error originates outside components-rs/. There are no failures attributable to
appsec helper-rust or the profiler independently — those crates do not use the
changed APIs (FixedAggregationKey, Trilean, or libdd_remote_config::Target).

After the changes below, the crate should compile and the full pipeline should
recover. (I cannot run cargo/make in this environment, so this is reasoned from
the error messages and the new libdatadog source.)

Non-trivial changes made

components-rs/remote_config.rs

libdatadog commits eaf5ad066 (refactor(libdd-remote-config)!: hide Target
inner properties) and 85ce322a1 (fix(rc): Make Target fields available
again) changed libdd_remote_config::Target:

• All fields are now private; construction must go through the new
  Target::new(service, env, app_version, tags, process_tags) constructor.
• tags and process_tags are now Vec<String> (already-formatted
  "key:value" strings) instead of Vec<Tag>.
• Field reads go through accessor methods: service(), env(), app_version().

Changes:

1. ddog_remote_configs_service_env_change: replaced the Target { .. } struct
   literal with Target::new(..). The &libdd_common_ffi::Vec<Tag> inputs are
   converted to Vec<String> via .as_slice().iter().map(|t| t.to_string())
   — Tag implements Display/AsRef<str>, and to_string() yields the
   "key:value" form the new API documents as expected.
2. ddog_send_debugger_diagnostics: t.service.as_str() → t.service()
   (the accessor already returns &str).

components-rs/stats.rs

libdatadog change to FixedAggregationKey.is_trace_root: the field type changed
from bool to libdd_trace_protobuf::pb::Trilean (a 3-valued
NotSet/True/False protobuf enum). This mirrors the internal conversion in
libdd-trace-stats/src/span_concentrator/aggregation.rs.

• Added use libdd_trace_protobuf::pb::Trilean;.
• build_fixed_key: is_trace_root: span.is_trace_root →
  if span.is_trace_root { Trilean::True } else { Trilean::False }, matching the
  library's own bool → Trilean mapping (a plain bool maps to True/False,
  never NotSet).

components-rs/Cargo.toml

Added a path dependency on libdd-trace-protobuf so Trilean can be named.
libdd-trace-stats does not re-export the pb module, and the crate was not
previously a direct dependency. Added path-only (matching the other libdd-*
entries):

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

Identified libdatadog issues

None identified. All four breakages are intentional, documented API changes on
the libdatadog side (breaking-change commits marked !), each with a clear new
API to call. No panics or regressions originating inside libdatadog were found.

Flaky / ignored failures

None. Every one of the 176 failures is a deterministic compile error with the
same root cause; there are no timing/race/flaky or unrelated-infrastructure
failures in this run.

---

/cc @bwoebi

[datadog-prod-us1-3]

 

✨ Unblock PR with BitsAI

⚠️ Warnings

🚦 1627 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-php | appsec integration tests: [test8.5-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 | Debian_11_amd64.SID0: [test-app-php]     

DataDog/apm-reliability/dd-trace-php | Debian_12_amd64.SI94: [test-app-php-container-83]     

View all 1627 failed jobs.

ℹ️ Info

No other issues found (see more)

❄️ No new flaky tests detected

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

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: bf528c4 | 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%]