libdatadog update to 09d307dd

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	cea1e44edddd9124f75d5095f31026904a1f58d8
New	09d307ddca49f32a82f25d16719bbd64c1218924

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

---

libdatadog Integration Report

libdatadog SHA: 09d307ddca49f32a82f25d16719bbd64c1218924
Analysis date: 2026-05-21

Overall status

⚠️ Adapted (API changes fixed) — but the 64 reported CI failures are not API failures. Every failed job aborted in the CI infrastructure layer before any Rust code was compiled, so this run does not actually exercise the new libdatadog. No Rust source files in dd-trace-php were changed.

Build & test summary

The CI summary lists 64 failed jobs across two sub-pipelines:

Sub-pipeline	Jobs	Manifestation
tracer-trigger	compile extension: debug:* and compile extension: debug-zts-asan:* (all PHP versions × amd64/arm64) and aggregate tested versions	fatal: detected dubious ownership in repository at '/go/src/github.com/DataDog/apm-reliability/dd-trace-php/libdatadog'
package-trigger	compile tracing extension*, compile tracing extension asan*, compile tracing sidecar:*	Unknown option: -C (followed by git usage banner)

Both manifestations come from the same line in the generated CI YAML, injected by .gitlab/generate-common.php:117:

- git -C libdatadog fetch --depth=1 origin "$_libdatadog_sha" 2>&1
- git -C libdatadog checkout FETCH_HEAD

This block is appended (via register_shutdown_function) to every job whose before_script references one of compile_extension.sh, build-sidecar.sh, build-tracing.sh, build-tracing-asan.sh, or build-profiler.sh whenever LIBDATADOG_OVERRIDE_SHA is set. It runs immediately after Updating/initializing submodules recursively… has checked out the pinned submodule SHA (cea1e44edddd9124f75d5095f31026904a1f58d8) and is meant to force-fetch the override SHA (09d307ddca49f32a82f25d16719bbd64c1218924) on top.

Two distinct images break that step:

1. tracer-trigger build images (PHP compile-extension stages) ship a modern git that enforces the safe.directory whitelist. The git -C libdatadog … invocation traverses into libdatadog/, which was just initialised by GitLab Runner running as a different uid, and git refuses to operate on it. Exit code 128, message: fatal: detected dubious ownership in repository at '.../libdatadog'.

2. package-trigger build images (sidecar/tracing-extension stages) ship a very old git that pre-dates the -C global option (added in git 1.8.5, Nov 2013). The first character of the option list is rejected before git ever notices what command is being invoked: Unknown option: -C + usage banner. Exit code 1.

Trace files inspected (representative sample, plus a grep -c across all 63):

• compile_tracing_sidecar:_[amd64,_x86_64-unknown-linux-gnu]_1705122301.txt — old-git failure.
• compile_extension:_debug:_[8.5,_amd64]_1705125460.txt — dubious-ownership failure.
• compile_tracing_extension_asan:_[8.5,_amd64,_x86_64-unknown-_1705125667.txt — dubious-ownership failure.
• compile_tracing_extension:_[7.0,_arm64,_aarch64-unknown-linu_1705122286.txt — old-git failure.

A search for the strings error[, ^error, or cargo: across tmp/artifacts/traces/*.txt returned zero matches, confirming no Rust compilation occurred in any of the 63 traces.

The 64th failure listed in ci_summary.txt ([tracer-trigger] aggregate tested versions) has no trace file in tmp/artifacts/traces/ — it is a downstream rollup job that fails because all of its upstreams failed; it is not itself broken.

Because no compile actually ran, this CI execution gives us no signal whatsoever about API compatibility between dd-trace-php and libdatadog 09d307ddc. The libdatadog changelog (tmp/artifacts/libdatadog_changelog.txt) does include two notable !-marked feature commits — feat(trace-utils)!: add from_string to span text (#2011) and feat!: add encoder from v04 to v1 (#1896) — that are plausibly source-breaking, but with no compile traces to point at, there is nothing concrete to adapt in this report.

Non-trivial changes made

No code changes required.

The only failure mode observed in this run lives in the SHA-override step injected by .gitlab/generate-common.php. That is a CI-image / shell-script problem, not a Rust API change. Editing dd-trace-php's Rust sources to "work around" git -C failing would be nonsensical. The actual fix has to be done in the CI infrastructure (or in .gitlab/generate-common.php), and the task's constraints explicitly exclude running build/test commands here, so I cannot verify whether such an edit unblocks the pipeline. Recommended directions for the team that owns this:

1. Replace git -C libdatadog <cmd> with (cd libdatadog && git <cmd>). That removes the dependency on git ≥ 1.8.5 and resolves the package-trigger failures.
2. Prepend git config --global --add safe.directory "$CI_PROJECT_DIR/libdatadog" (or safe.directory '*') before the fetch. That clears the dubious-ownership refusal on the tracer-trigger images. Equivalent inline form: git -c safe.directory=… ….
3. Once those two are in place, re-run the pipeline against LIBDATADOG_OVERRIDE_SHA=09d307ddca49f32a82f25d16719bbd64c1218924. That run will produce the first actually-meaningful compatibility signal for this SHA — at which point this analysis should be repeated against fresh traces.

I deliberately did not edit .gitlab/generate-common.php myself: it is outside the Rust-adaptation scope of this task, both fixes are unverifiable from this environment, and a wrong tweak to the SHA-override mechanism would silently make future libdatadog runs look like they passed when they did not.

Identified libdatadog issues

None identified. With no Rust compilation reaching libdatadog, no libdatadog defect can be observed or attributed.

Flaky / ignored failures

None. The 64 failures form a single deterministic CI-infrastructure failure class, not a flake. They will reproduce on every libdatadog-SHA-override scheduled run until the git -C step in .gitlab/generate-common.php is made portable across the build images.

---

/cc @bwoebi

[datadog-datadog-prod-us1]

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 1 Pipeline job failed

DataDog/apm-reliability/dd-trace-php | generate-templates     

🛟 This job is unlikely to succeed on retry. Please review your pipeline configuration.

Command 'git' not found during script execution.

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 56080c7 | 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 👍 / 👎.