libdatadog update to c690b5e4#4006
Conversation
Automated update by CI pipeline https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-php/-/pipelines/120400113 Full CI result: ❌ 2 job(s) failed
dd-octo-sts
Bot
requested review from
greghuels and
leoromanovsky
and removed request for
a team
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 91b5f2bade
ℹ️ 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".
| @@ -1 +1 @@ | |||
| Subproject commit cd90e50a5b067cf77a3e06641d838bc4c6b62aba | |||
| Subproject commit c690b5e43ccdf5ff84566db4447d416ac8c48ea8 | |||
There was a problem hiding this comment.
This bump points at a libdatadog revision that changes path package versions (libdd-common 4.2.0→5.0.0 and libdd-remote-config 0.1.0→1.0.0), but the parent Cargo.lock is unchanged and still records the old versions. I checked cargo build --help; --locked asserts the lockfile remains unchanged, so locked/reproducible builds from this commit will fail before compilation because Cargo must rewrite the lockfile for those path dependencies. Please regenerate and commit Cargo.lock with this submodule revision.
Useful? React with 👍 / 👎.
Automated update by CI pipeline https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-php/-/pipelines/120433298 Full CI result: ❌ 3 job(s) failed
Summary
Automated update of the libdatadog submodule to the latest HEAD.
$LIBDATADOG_PINNED_SHAc690b5e43ccdf5ff84566db4447d416ac8c48ea8Full CI result: ❌ 3 job(s) failed
CI pipeline: https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-php/-/pipelines/120433298
libdatadog Integration Report
libdatadog SHA: c690b5e43ccdf5ff84566db4447d416ac8c48ea8
Analysis date: 2026-06-23
Overall status
✅ Clean update — no API changes broke the build; the 3 remaining CI failures are
infrastructure timeouts / flaky test-harness failures unrelated to the libdatadog API.
Build & test summary
All compilation succeeded on every platform. There are no compilation-failure traces in
tmp/artifacts/traces/(the directory is empty), which means every Rust call site indd-trace-php still compiles against the new libdatadog FFI surface. This is notable given the
changelog contains many breaking (
!) changes — OTLP attribute-level export (#2091), client-computed span stats as OTLP metrics (#2067), the VecMap span representation (#2043 / #2022),
the change-buffer rewrite (#2055 / #2105 / #2046), trace-exporter FFI changes (#2051 / #2029),
crashtracking changes (#2054 / #2114 / #2099), and remote-config renames (#2102 / #2103). None
of these touched the API dd-trace-php actually consumes, so no source edits were required.
Sub-pipeline results (from
bridges.json):appsec integration tests: [test8.4-release])windows test_c: [7.2]and[7.3]timed outmin install testsscript failurePersistent failures after retries (
ci_summary.txt):windows test_c: [7.3]—failure_reason: job_execution_timeout, ran 3602s (exactly the 1h cap)windows test_c: [7.2]—failure_reason: job_execution_timeout, ran 3602s (exactly the 1h cap)min install tests—failure_reason: script_failureNon-trivial changes made
No code changes required. The new libdatadog API is source-compatible with dd-trace-php; the
entire Rust workspace compiled on all platforms.
Identified libdatadog issues
None identified. No panic, regression, or behavioural failure could be traced back to a
libdatadog code path. There are no compilation traces and no captured job logs for the failing
jobs (no
job.logwas downloaded into the artifacts directory and themin install testsartifacts.zipwas not extracted), so there is no evidence of a libdatadog defect. Because thebuild is clean, none of the breaking changes in the changelog require a workaround.
Flaky / ignored failures
windows test_c: [7.2]andwindows test_c: [7.3]— both hitjob_execution_timeoutat exactly the 3602s (1 hour) job cap rather than failing a testassertion. The Windows V2 2019 group runners are slow and these C-extension test jobs
routinely brush the timeout. Decisive evidence that this is infrastructure rather than this
specific update: the parent commit (
8499f598d, the previous automated libdatadog update)also recorded "❌ 2 job(s) failed" — i.e. the same two Windows test_c jobs fail across
successive, unrelated libdatadog updates. Timeouts of this shape match the "timing / flaky"
ignore rule. Recommend re-running the Windows jobs.
min install tests(package-trigger, verify stage) —script_failurewith no compilationtrace and no captured log available for analysis. The package itself built successfully (this
is a post-build install/smoke verify job, not a build job), so it is not an API-compatibility
failure. With no diagnostic output and a clean build, this is most consistent with a flaky /
environmental verify failure (e.g. download/install of a dependency in the minimal install
environment). Recommend a re-run; if it persists across re-runs, pull the job log
(
artifacts.zip/job.log) for a follow-up investigation, as it would then point to apackaging/environment regression rather than the libdatadog Rust API.
appsec integration tests: [test8.4-release]andtest early PHP 8.1— appear inretried_jobs.tsvbut not in the final persistent-failure set, meaning they passed on retry.Classic flakes; no action.
/cc @bwoebi