libdatadog update to 276039da

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	cea1e44edddd9124f75d5095f31026904a1f58d8
New	276039da8897a8e9e83ed3162912792f2241c5d7

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

---

libdatadog Integration Report

libdatadog SHA: 276039da8897a8e9e83ed3162912792f2241c5d7
Analysis date: 2026-05-24

Overall status

⚠️ Blocking issues remain — but they are CI infrastructure problems, not libdatadog API issues. No Rust code was actually exercised against the new libdatadog, so API compatibility could not be assessed from this run.

Build & test summary

All 51 failed jobs are in the compile stage. They fall into two clusters:

• 50 jobs (compile extension: … and compile tracing extension asan: …) — fail at the very first build step, before any Rust compilation. The command
  git -C libdatadog fetch --depth=1 origin "276039da8897a8e9e83ed3162912792f2241c5d7"
  aborts with:

  fatal: detected dubious ownership in repository at '/go/src/github.com/DataDog/apm-reliability/dd-trace-php/libdatadog'
To add an exception for this directory, call: git config --global --add safe.directory …
  This is git's safe.directory protection rejecting the submodule because the working tree owner differs from the user running git inside the build container. The job exits with code 128 before make, cargo, or phpize is ever invoked.

• 1 job (compile extension: debug: [7.1, arm64]) — failed with Kubernetes pod-scheduling failures (no nodes available, repeated Insufficient cpu events). The build never started.

• 1 downstream job (aggregate tested versions) — failed because the per-version compile jobs it aggregates all failed.

Net effect: zero traces show any Rust/C compilation actually running. There is no signal in this CI run about whether libdatadog 276039da8 is API-compatible with our code.

Spot-checking the libdatadog changelog since the previously pinned SHA (tmp/artifacts/libdatadog_changelog.txt) shows 11 commits, with two breaking changes flagged by the ! convention:

• ecdca7d4e feat(trace-utils)!: add from_string to span text (#2011)
• e2fb8860d feat!: add encoder from v04 to v1 (#1896)

Whether these affect dd-trace-php cannot be determined without a real build; they should be re-evaluated once the CI infrastructure issue is resolved and a fresh pipeline runs.

Non-trivial changes made

No code changes required. Every failure occurs before any dd-trace-php Rust source is compiled, so there is no compiler error to adapt to. Editing source files in response to these failures would be speculative and would not turn any of the red jobs green — the jobs fail at git fetch, well before they would read any .rs file.

Identified libdatadog issues

None identified. The failures originate entirely in dd-trace-php's GitLab CI runner / submodule-fetching step. The libdatadog tree at 276039da8 was not yet checked out at the point of failure, so it had no opportunity to misbehave.

Flaky / ignored failures

All 51 failures are ignored for the purpose of libdatadog API analysis, on the grounds described above:

• 50 × dubious ownership — CI environment issue. The runner needs git config --global --add safe.directory /go/src/github.com/DataDog/apm-reliability/dd-trace-php/libdatadog (or equivalent ownership fix) before the submodule git fetch. Fix belongs in the CI pipeline configuration / runner image, not in this repo's source. Not a libdatadog bug.
• 1 × compile extension: debug: [7.1, arm64] — Kubernetes scheduling exhaustion (0/N nodes are available: Insufficient cpu). Transient capacity issue; would be expected to pass on retry once the safe.directory issue is also resolved.
• 1 × aggregate tested versions — Pure downstream cascade from the compile failures above. Will pass automatically once the upstream jobs do.

Recommendation

Re-run this CI pipeline after the GitLab runner image / before-script is updated to mark the libdatadog submodule directory as a safe directory for git. Only then will it be possible to actually evaluate whether 276039da8 is API-compatible with dd-trace-php.

---

/cc @bwoebi

[datadog-datadog-prod-us1]

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 12 Pipeline jobs failed

Profiling correctness | prof-correctness (8.0, nts)     

🔧 Fix in code (Fix with Cursor).

Compilation error in libdatadog/libdd-profiling/src/internal/profile/interning_api/mod.rs:237: use of unstable library feature `unsigned_is_multiple_of`.

Profiling correctness | prof-correctness (8.0, zts)     

🔧 Fix in code (Fix with Cursor).

Use of unstable library feature `unsigned_is_multiple_of` in libdatadog/libdd-profiling/src/internal/profile/interning_api/mod.rs:237:20

Profiling correctness | prof-correctness (8.1, nts)     

🔧 Fix in code (Fix with Cursor).

Compilation error: use of unstable library feature `unsigned_is_multiple_of` in libdatadog/libdd-profiling/src/internal/profile/interning_api/mod.rs:237:20.

View all 12 failed jobs.

Useful? React with 👍 / 👎

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5e412997b4

ℹ️ 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]

Revert submodule bump to failing libdatadog revision

This change advances libdatadog to 0f839576, but the commit metadata for this exact update reports a full CI failure (64 failed jobs in pipeline 114403599), which indicates the pinned revision is not currently integration-safe for dd-trace-php. Merging this pointer as-is will keep the main branch on a known-bad dependency state across the tested matrix; keep the previous SHA until the upstream breakage is fixed or a known-good follow-up SHA is identified.

Useful? React with 👍 / 👎.