libdatadog update to 35f26ee0

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	$LIBDATADOG_PINNED_SHA
New	35f26ee0d0e25267a5b292acbe7f828efdca4c2a

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

---

libdatadog Integration Report

libdatadog SHA: 35f26ee0d0e25267a5b292acbe7f828efdca4c2a
Analysis date: 2026-07-29

Overall status

✅ Clean update

No API incompatibilities. The single persistent CI failure is an
allow_failure: true release/infrastructure job that does not build or link
libdatadog.

Build & test summary

tmp/artifacts/ci_summary.txt reports 1 persistent failure after the
automatic retry pass:

Sub-pipeline	Bridge status at collection	Persistent failures
shared-trigger (127619208)	success	none
appsec-trigger (127619205)	success	none
package-trigger (127619217)	success	publish docker image for system tests
profiler-trigger (127619206)	failed	none — retried green
tracer-trigger (127619245)	failed	none reported (see caveat)

tmp/artifacts/traces/ is empty. That is meaningful rather than a
collection error: .gitlab/libdatadog-latest.yml:189-208 only downloads job
traces for jobs whose name matches compile build sidecar tracing profil appsec. An empty traces directory therefore means no compile-, build-,
sidecar- or link-class job failed — i.e. every Rust/C/C++ compilation unit
built against the new libdatadog.

Actual libdatadog delta

tmp/artifacts/libdatadog_changelog.txt contains exactly 100 entries and
includes the previously pinned SHA itself, which means the
git log <pinned>..HEAD in .gitlab/libdatadog-latest.yml:182 failed and the
git log --oneline -100 fallback ran. The changelog is therefore not the
delta. The real delta (git log f2010b616..35f26ee0d, previous pin taken from
git show HEAD -- libdatadog) is 5 commits:

Commit	Breaking	Relevance to dd-trace-php
35f26ee0d fix(sidecar): send eof chunk in datagram test	no	test-only change in datadog-sidecar/src/crashtracker.rs
4a0e5bc70 feat(rc): Handle expired config status	no	libdd-remote-config/src/fetch/fetcher.rs internals + a test; no public API change (diff adds only async fn test_expired_config_status_drops_all_configs)
63a872a03 chore: bump workspace version to 38.0.0	no	irrelevant — every libdatadog crate is a path dependency in components-rs/Cargo.toml and profiling/Cargo.toml with no version requirement
79eff2fa1 refactor(trace-utils)! split generic TracerHeaderTags	yes	not reachable from our code (see below)
95610de06 feat(remote-config)! add AsmRawResponseBody capability	yes	purely additive (see below)

79eff2fa1 — TracerHeaderTags split

The commit moves client_computed_stats, client_computed_top_level,
dropped_p0_traces and dropped_p0_spans out of
libdd_trace_utils::trace_utils::TracerHeaderTags into a new nested
TracerGenericTags (libdd-trace-utils/src/tracer_header_tags.rs:22-52).

This does not reach us on either boundary:

• Rust. Our only libdd_trace_utils imports are
  components-rs/bytes.rs:3 (span::v04::SpanBytes) and
  components-rs/trace_filter.rs:17 (trace_filter::{Span, TraceFilterer}).
  Neither module was touched. Nothing in components-rs/, profiling/ or
  appsec/ names TracerHeaderTags, TracerGenericTags,
  client_computed_* or dropped_p0_*.
• FFI/C. The struct our C code passes to
  ddog_sidecar_send_trace_v04_* is the separate #[repr(C)]
datadog_sidecar_ffi::TracerHeaderTags
  (libdatadog/datadog-sidecar-ffi/src/lib.rs:791-800), which still has the
  four flags flat. The commit only changed how that struct is converted
  internally (lib.rs:810-817). The checked-in cbindgen output
  components-rs/common.h:1211-1220 still matches it field for field, so
  there is no stale-ABI hazard.

95610de06 — AsmRawResponseBody

Appends AsmRawResponseBody = 49 after LlmObsActivation = 48 and marks the
enum #[non_exhaustive] (libdd-remote-config/src/lib.rs:82,133). Appending
leaves every existing discriminant unchanged, and #[non_exhaustive] only
constrains exhaustive match on the enum — components-rs/remote_config.rs
merely constructs and pushes variants (lines 146-181) and never matches on
it. No adaptation needed.

Non-trivial changes made

No code changes required.

Two deliberate non-changes worth recording:

• components-rs/common.h was not regenerated. It is cbindgen output
  (make cbindgen, Makefile:423-457) and is now missing only the unused
  DDOG_REMOTE_CONFIG_CAPABILITIES_ASM_RAW_RESPONSE_BODY = 49 constant. No
  value we use changed, so nothing is broken; hand-editing generated headers
  would be worse than leaving them. A regeneration on the next make cbindgen
  run will pick it up.
• Advertising the new AsmRawResponseBody capability from
  components-rs/remote_config.rs would be a feature (appsec raw response
  body collection, RFC-115), not a compatibility adaptation, so it is out of
  scope here.

Identified libdatadog issues

None identified.

Flaky / ignored failures

• [profiler-trigger] PHP language tests: [8.5, amd64, zts] — failed on
  the first attempt, passed on the automatic retry
  (tmp/artifacts/retried_jobs.tsv). Flaky; nothing to do.

• [package-trigger] publish docker image for system tests — the one
  persistent failure. Ignored as unrelated to libdatadog:
  .gitlab/generate-package.php:1584-1673 defines it as a stage: release
  job with GIT_STRATEGY: none and allow_failure: true. It compiles
  nothing: it reads a dd-octo-sts token, queries the GitHub PR API, and does
  docker buildx build --push of a FROM scratch image containing the
  already-built tarballs. It cannot be affected by a libdatadog API change.

  I could not read its log to pin the exact cause — the trace was not
  collected (the job name matches none of the compile build sidecar tracing profil appsec keywords), and this environment has no
  GITLAB_PERSONAL_ACCESS_TOKEN (a JOB-TOKEN request to
  /projects/355/pipelines/*/jobs returns 404 Project Not Found). From the
  script, the two plausible causes are both branch/registry plumbing:

  1. exit 3 at line 1623 — "No open PR for branch"; on bot/libdatadog-latest
     the PR is created by analyze-and-create-pr, which needs: package-trigger (.gitlab-ci.yml:171-178) and so runs after this job,
     making the check racy on the bot branch;
  2. a transient ghcr.io login / buildx --push failure.

Caveat on CI coverage

tmp/artifacts/bridges.json records tracer-trigger (pipeline 127619245)
with downstream_pipeline.status: failed, yet collect_failures found no
failed job in it and it appears in neither all_failures.json nor
retried_jobs.tsv. The explanation is the collector's use of
/pipelines/:id/jobs, which defaults to include_retried=false: the tracer
pipeline's test jobs carry retry: 2 / retry: {max: 2}
(.gitlab/generate-tracer.php:240,537), so a failed attempt that GitLab had
already auto-retried is hidden behind the newer in-flight attempt.

So a tracer-pipeline job did fail at least once, but it was a GitLab-auto-retried
(transient-class) failure and its final outcome is not in these artifacts. It
was not a compile failure — those job names contain compile, which the trace
collector would have captured. I am flagging this rather than claiming the
tracer pipeline was green end to end.

---

/cc @bwoebi

[datadog-datadog-prod-us1-2]

 

✨ Unblock PR with BitsAI

⚠️ Warnings

🚦 7 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-php | test_extension_ci: [7.3]     

DataDog/apm-reliability/dd-trace-php | test_extension_ci: [8.2]     

DataDog/apm-reliability/dd-trace-php | test_extension_ci: [7.4]     

View all 7 failed jobs.

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

🔄 Datadog auto-retried 3 jobs - 1 passed on retry

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 60.65% (+0.00%)

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 0f72f90 | Docs | Datadog PR Page | Give us feedback!}

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2026-07-27 11:22:15

Comparing candidate commit 5b69580 in PR branch bot/libdatadog-latest with baseline commit 39036dc in branch master.

Found 1 performance improvements and 3 performance regressions! Performance is the same for 190 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:PDOBench/benchPDOOverhead

• 🟥 execution_time [+6.700µs; +9.215µs] or [+2.604%; +3.582%]

scenario:PDOBench/benchPDOOverheadWithDBM

• 🟥 execution_time [+6.932µs; +9.417µs] or [+2.695%; +3.661%]

scenario:PHPRedisBench/benchRedisOverhead

• 🟥 execution_time [+35.739µs; +45.514µs] or [+3.534%; +4.501%]

scenario:SamplingRuleMatchingBench/benchRegexMatching1-opcache

• 🟩 execution_time [-10.799µs; -10.564µs] or [-87.038%; -85.137%]