libdatadog update to 836ff60a

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	$LIBDATADOG_PINNED_SHA
New	836ff60ac46244268c6b62b5246132a08cf09512

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

---

libdatadog Integration Report

libdatadog SHA: 836ff60ac46244268c6b62b5246132a08cf09512
Analysis date: 2026-09-26

Overall status

⚠️ Adapted (API changes fixed)

The code changes could not be compiled locally because no Rust toolchain is
available here. They are based on the error messages and the libdatadog source.

Build & test summary

246 jobs failed across the tracer, appsec, profiler, shared and package
sub-pipelines. All 111 available traces fail during the Rust build, for one of
two reasons. In the table, "Jobs" is the number of trace files showing that
error:

#	Error	Jobs	Cause
1	`dependency.winapi` was not found in `workspace.dependencies` while parsing libdatadog/datadog-sidecar/Cargo.toml	66	libdatadog now declares every dependency at workspace level (a5e71645f, ea4379c9c)
2	error[E0599]: no variant ... named AsmRawResponseBody found for enum RemoteConfigCapabilities at components-rs/remote_config.rs:199	45	The variant was removed in 03cead969 (#2540)

Error 1 stops cargo before it compiles anything. It hits every job that runs
cargo from the dd-trace-php workspace: profiler builds, clippy NTS,
Cargo test, helper-rust build/coverage, and the appsec integration tests
(buildPortableLibdatadogPhp). Error 2 hits the jobs that did get as far as
compiling (the appsec extension and tracer builds). rustc reported
"1 previous error" for the datadog-php crate, so there were no other type
errors in it. ddtrace-sidecar compiled before that point.

The failures without a trace file depend on the same Rust build:

• Extension Tea Tests run make install, which builds ddtrace.so with cargo.
• ZAI tests use zend_abstract_interface/components_rs.cmake, which runs cargo
  on components-rs.
• pecl tests, PHP language tests, and the system-tests docker image all build
  the extension or profiler.

So they fail as a knock-on effect of these two errors. No test failures
unrelated to the build were seen.

Non-trivial changes made

Cargo.toml (root [workspace.dependencies])

dd-trace-php's root manifest is the workspace root for all libdatadog/*
crates. After the libdatadog update, those crates inherit dependency versions
from our root with x.workspace = true instead of pinning versions
themselves. Crates in our dependency graph now inherit dependencies that our
root did not declare. Cargo resolves these when it parses the manifest, even
for Windows-only or optional dependencies. I added the missing entries, copied
from libdatadog/Cargo.toml:

Entry	Crate that inherits it
winapi = "0.3.9"	datadog-sidecar, libdd-ipc (Windows)
windows = "0.59.0"	libdd-crashtracker, libdd-crashtracker-ffi (Windows)
windows-sys = "0.52"	Kept to match libdatadog's workspace
kernel32-sys = "0.2.2"	spawn_worker (Windows)
cbindgen = "0.29"	build-common (build dependency of the *-ffi crates)
opentelemetry-proto = "0.33"	libdd-profiling (optional otel feature)
blazesym-c = "=0.1.7"	symbolizer-ffi

All entries use default-features = false, like libdatadog does. libdatadog
now spells out the features it needs (for example "std" for windows).

I also raised three minimum versions to match libdatadog's workspace, since
libdatadog crates now take these versions from our root:

• hyper: 1.6 → 1.11. Cargo.lock currently pins 1.6.0.
• tokio: 1.36 → 1.49.
• pyo3: 0.28 → 0.29. libdd-ffe moved to 0.29 in f4c19fc4a; pyo3 is only
  pulled in by an optional feature.

Cargo.lock is not updated here (no cargo available). CI does not use
--locked, so cargo will refresh the lockfile. It should be regenerated and
committed.

components-rs/remote_config.rs, components-rs/common.h

• Removed RemoteConfigCapabilities::AsmRawResponseBody from the capabilities
  that ddog_init_remote_config advertises.
• Removed DDOG_REMOTE_CONFIG_CAPABILITIES_ASM_RAW_RESPONSE_BODY = 49 from
  the checked-in cbindgen header, so it matches the new enum.

libdatadog commit 03cead969 explains the removal: "AsmRawResponseBody only
exists in libdatadog and dd-trace-php and uses a value that had already been
taken on top of it. Remove it for now". The PHP tracer therefore stops
advertising capability bit 49. The appsec feature itself
(DD_APPSEC_RAW_RESPONSE_BODY_ENABLED, in appsec/src/extension/entity_body.c
and request_shutdown.c) is not affected. No C code referenced the removed
enum constant.

appsec integration test fixtures

• appsec/tests/integration/.../mock_agent/rem_cfg/Capability.groovy: removed
  ASM_RAW_RESPONSE_BODY(49).
• appsec/tests/integration/.../integration/RemoteConfigTests.groovy: removed
  Capability.ASM_RAW_RESPONSE_BODY from the list of capabilities the test
  expects. The test itself still runs and checks every other capability.
  Keeping the expectation would assert a capability that upstream removed on
  purpose because its bit number clashed with another one.

Identified libdatadog issues

None identified that block this update. One follow-up:

• Raw response body has no remote-config capability. Removing the variant
  means dd-trace-php can no longer tell the backend that it supports raw
  response bodies. This was deliberate upstream (bit 49 clashed with an
  existing one), not a bug. The appsec team needs to get a proper capability
  number registered and added back to libdatadog, then re-add it in
  components-rs/remote_config.rs and the integration test.

Flaky / ignored failures

None. All 246 failures trace back to the two build errors above.

---

/cc @bwoebi

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2026-09-26 04:18:52

Comparing candidate commit 98bbcaa in PR branch bot/libdatadog-latest with baseline commit 5fe256c in branch master.

📊 Benchmarking dashboard

Found 1 performance improvements and 1 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:HookBench/benchWithoutHook

• 🟥 execution_time [+2.139µs; +4.965µs] or [+2.620%; +6.082%]

scenario:MessagePackSerializationBench/benchMessagePackSerialization-opcache

• 🟩 execution_time [-4.227µs; -2.653µs] or [-3.654%; -2.294%]

[cataphract]

Blocked by #3725