[bwoebi]

8.6.0RC7 and final release have a new ABI version.

Containers are already rebuilt.

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-13T00:01:41.208206Z	a4eec10	PR opened
🔒 Security Review	✅ Completed 2026-11-13T00:03:14.394081Z	a4eec10	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a4eec10f51

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve the original ABI boundary for PHP 8.6 logging

On earlier PHP 8.6 release candidates using API 20260924, enabling DD_TRACE_DEBUG now makes ddloader_logv() take the pre-8.6 branch and pass a char * to _php_error_log(), even though those runtimes already require a zend_string *. This can crash PHP during the initial REASON_START telemetry call, before the loader can handle missing or incompatible extensions. Keep the logging-signature threshold at the API where that signature originally changed, independently of the new packaging ABI.

Useful? React with 👍 / 👎.

[datadog-prod-us1-5]

The ABI update also moves a logging compatibility cutoff, causing earlier PHP 8.6 release candidates to pass the wrong argument type to PHP’s error logger when debug logging is enabled. The cutoff should retain its original value.

_{Open Bits AI session}

_{🤖 Bits Code Review · Commit a4eec10}

[datadog-prod-us1-5]

Preserve the logging cutoff for earlier PHP 8.6 runtimes

On earlier PHP 8.6 release candidates such as RC3, enabling DD_TRACE_DEBUG=1 now selects the legacy logging branch because their API number is 20260924. Those runtimes already require zend_string*, so _php_error_log() interprets a raw message buffer using the wrong layout, corrupting loader diagnostics. Startup logging occurs before package compatibility checks, so removing older extension binaries does not prevent this. Preserve the original logging cutoff independently of the maximum supported ABI.

Suggested change

	#define PHP_86_VERSION 20261112
	#define PHP_86_VERSION 20260924

React: 👍 useful · 👎 wrong · 😕 unclear · 👀 right, but not acting on it

What each reaction means

• 👍 Useful: correct, and you're fixing it or will.
• 👎 Wrong: the finding is incorrect, for example the bug can't happen or the code was misread.
• 😕 Unclear: you can't tell what it means or why it matters.
• 👀 Right, not acting: correct, but intended, out of scope for this PR, a known risk, or too minor.

_{🤖 Bits Code Review · Open Bits AI session}

[datadog-prod-us1-5]

 

✨ Unblock PR with BitsAI

❌ Errors

Your PR has failed checks. Please review the issues below and take necessary action before merging.

🚦 156 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-php | PHP Language Tests: [8.6] — ❄️ 999 known flaky tests

View more details · View in GitLab

↳ ❄️ Known flaky: Zend/tests/67468.phpt (Bug #67468 (Segfault in highlight_file()/highlight_string())) from php.Zend.tests

↳ ❄️ Known flaky: Zend/tests/ErrorException_construct.phpt (Test default value handling of ErrorException::__construct()) from php.Zend.tests

↳ and 997 more — View all

DataDog/apm-reliability/dd-trace-php | PHP language tests: [8.6, arm64, nts] — ❄️ 1 known flaky test

View more details · View in GitLab

↳ ❄️ Known flaky: Zend/tests/zend_alloc_realloc_shrink_boundary.phpt (erealloc() of a small block keeps it in the bin its new size maps to) from php.Zend.tests

DDCI - DataDog/dd-trace-php | API unit tests: [8.6] — 🔧 Needs a code fix, caused by this PR

View more details · View in DDCI

View all 156 failed jobs.

ℹ️ Info

No other issues found (see more)

❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 80.13% (-0.00%)

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: b664cf3 | Docs | View more details | Give us feedback!}

[datadog-prod-us1-5]

PHP 8.6 RC3 with debug logging now reaches a logging call with the wrong argument type, risking a startup crash. The AppSec integration configuration still selects that runtime and enables debug logging.

_{Open Bits AI session}

_{🤖 Bits Code Review · Commit 870dc4d}

[datadog-prod-us1-5]

Preserve the original logging-signature ABI cutoff

On PHP 8.6 RC3 (ABI 20260924) with DD_TRACE_DEBUG=1, this new cutoff makes ddloader_logv() pass a char buffer to _php_error_log(), which already expects a zend_string pointer. That invalid argument can crash PHP during the initial injection log. The AppSec integration configuration still selects RC3 and enables debug logging. Keep the logging-signature cutoff at 20260924 independently of the latest supported ABI.

Suggested change

	#define PHP_86_VERSION 20261112
	#define PHP_86_VERSION 20260924

React: 👍 useful · 👎 wrong · 😕 unclear · 👀 right, but not acting on it

What each reaction means

• 👍 Useful: correct, and you're fixing it or will.
• 👎 Wrong: the finding is incorrect, for example the bug can't happen or the code was misread.
• 😕 Unclear: you can't tell what it means or why it matters.
• 👀 Right, not acting: correct, but intended, out of scope for this PR, a known risk, or too minor.

_{🤖 Bits Code Review · Open Bits AI session}

[datadog-prod-us1-5]

The ABI constant also controls the loader’s logging signature. Raising it makes debug logging on earlier PHP 8.6 builds pass an incompatible argument to PHP, potentially crashing during startup.

_{Open Bits AI session}

_{🤖 Bits Code Review · Commit b664cf3}

[datadog-prod-us1-5]

Preserve the logging cutoff for earlier PHP 8.6 builds

On earlier PHP 8.6 builds with API 20260924 and DD_TRACE_DEBUG=1, this change selects the char* logging call although _php_error_log() already expects zend_string*. The first startup message reaches this call before compatibility checks, potentially crashing PHP. AppSec images still pin RC3. Preserve the original logging cutoff independently of the updated artifact ABI.

Suggested change

	#define PHP_86_VERSION 20261112
	#define PHP_86_VERSION 20260924

React: 👍 useful · 👎 wrong · 😕 unclear · 👀 right, but not acting on it

What each reaction means

• 👍 Useful: correct, and you're fixing it or will.
• 👎 Wrong: the finding is incorrect, for example the bug can't happen or the code was misread.
• 😕 Unclear: you can't tell what it means or why it matters.
• 👀 Right, not acting: correct, but intended, out of scope for this PR, a known risk, or too minor.

_{🤖 Bits Code Review · Open Bits AI session}

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2026-11-13 02:55:07

Comparing candidate commit b664cf3 in PR branch bob/php-8.6-rc7-abi with baseline commit 2d3e2b7 in branch master.

📊 Benchmarking dashboard

Found 1 performance improvements and 0 performance regressions! Performance is the same for 221 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:SamplingRuleMatchingBench/benchRegexMatching4

• 🟩 execution_time [-128.002ns; -73.398ns] or [-8.052%; -4.617%]