Summary

Automated update of the libdatadog submodule to the latest HEAD.

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

libdatadog Integration Report

libdatadog SHA: 6760faaeeda1cfcf634410105f93cf7149265592
Analysis date: 2026-06-12

Overall status

⚠️ Adapted (API changes fixed)

Build & test summary

17 jobs were reported as failed. They fall into three groups:

1. Rust compilation failures (13 jobs) — root cause, now fixed.

   • compile extension: debug: [8.5, arm64]
   • compile tracing extension asan: [...] for 7.4 / 8.0 / 8.1 / 8.2 / 8.3 / 8.4 / 8.5 on both
     aarch64-unknown-linux-gnu (arm64) and x86_64-unknown-linux-gnu (amd64)

   All failed with the identical error:

   error[E0599]: no method named `remove` found for struct `VecMap` in the current scope
     --> components-rs/bytes.rs:249 / 254 / 293 / 319
   help: there is a method `remove_slow` with a similar name
   

   This is a direct consequence of new libdatadog commit
   74284cac7 refactor(span)!: use VecMap for meta, metrics and meta_struct for v04 spans,
   which replaced the HashMap-backed maps on SpanBytes with the new VecMap type.
   VecMap deliberately renames the removal method to remove_slow (it is O(n) via
   Vec::retain, unlike a hashmap). Fixed by updating the 4 call sites (see below).

2. Downstream jobs blocked by the compile failure (2 jobs).

   • aggregate tested versions
   • pecl tests: [7.0]

   These consume the extension artifacts produced by the compile stage. They failed because the
   Rust library never built (script_failure); they are expected to pass once the compile fix
   above lands. No code change of their own is required.

3. Unrelated / flaky (2 jobs). See "Flaky / ignored failures".

Once the remove_slow change is in place, the entire compile fan-out and its dependent jobs
should build and run again.

Non-trivial changes made

• components-rs/bytes.rs — SpanBytes.meta and SpanBytes.metrics are now VecMap
  instead of HashMap. The VecMap removal method is named remove_slow (the rename signals
  its linear-scan cost). Renamed the 4 call sites accordingly; the semantics are unchanged
  (remove_slow removes all entries matching the key):

  • line 249 ddog_del_span_meta_zstr: ptr.meta.remove(...) → ptr.meta.remove_slow(...)
  • line 254 ddog_del_span_meta_str: ptr.meta.remove(...) → ptr.meta.remove_slow(...)
  • line 293 ddog_del_span_metrics_zstr: ptr.metrics.remove(...) → ptr.metrics.remove_slow(...)
  • line 319 ddog_del_span_metrics_str: ptr.metrics.remove(...) → ptr.metrics.remove_slow(...)

  The other VecMap accessors we use (insert, get, contains_key) keep their names, so no
  further changes were needed. Verified there are no other VecMap::remove call sites in our
  Rust sources (the remaining .remove( calls in components-rs/ operate on HashMap/HashSet).

Identified libdatadog issues

None identified. The remove → remove_slow rename is an intentional breaking API change
(commit 74284cac7, marked !), and the new method is a clean drop-in replacement with the
same delete-all-matching-keys semantics. The other breaking changes in the changelog
(feat(native-spans)! #2046, refactor(rc-fetcher)! #2103, feat(crashtracking)! #2099) did
not surface any compilation errors against our code.

Flaky / ignored failures

• appsec integration tests: [test8.4-release] — 344 tests ran, 1 failed:
  TelemetryExtendedHeartbeatTests > extended heartbeat re-emits configuration, dependencies and integrations() with phpredis not emitted via app-started/app-integrations-change; saw: []; flushed = []. This is a telemetry integration test asserting on the flushed integrations list,
  which came back empty — a timing/flush race unrelated to the libdatadog span-map change. Ignored
  as flaky.
• windows test_c: [7.2] and windows test_c: [7.3] — both failed with
  job_execution_timeout (not a script_failure/compile error). No compilation trace was
  produced. Treated as infrastructure timeout / flakiness, unrelated to the libdatadog API change.

/cc @bwoebi