[leoromanovsky]

Motivation

PHP applications need to fetch feature flag configuration from the CDN and evaluate flags without running a Datadog Agent.

flowchart LR
    CDN[Flag configuration CDN] -. missing activation .-> PHP[PHP feature flag provider]
    Agent[Datadog Agent] --> RC[Remote Configuration] --> PHP

Loading

Changes and Decisions

Fetch managed or custom CDN configuration in the libdatadog sidecar subprocess and deliver snapshots to PHP through shared memory. The first native or OpenFeature evaluation starts a subscription with a bounded initialization wait. Evaluations retain the last valid configuration across HTTP failures and sidecar restarts. Custom endpoints never receive the Datadog API key. Invalid settings produce redacted warnings on first use; evaluation details distinguish permanent setup failures from configuration still loading.

PHP reconnects and resubscribes after a sidecar restart, and resumes its readers after fork. CDN configuration is shared across PHP threads; Remote Configuration retains its existing thread isolation. Explicit sidecar thread mode leaves the CDN provider unavailable because configuration HTTP requires a subprocess.

Depends on libdatadog #2675 and #2676.

Caller usage

With the candidate extension installed, set these before starting PHP:

export DD_FEATURE_FLAGS_ENABLED=true
export DD_FEATURE_FLAGS_CONFIGURATION_SOURCE=agentless
export DD_API_KEY="<DATADOG_API_KEY>"
export DD_SITE=datadoghq.com
export DD_SERVICE=checkout
export DD_ENV=production

Native PHP:

$flags = new \DDTrace\FeatureFlags\Client();
$layout = $flags->getStringValue('checkout-layout', 'control', [
    'targetingKey' => 'user-123',
]);

$details = $flags->getStringDetails('checkout-layout', 'control');
$state = $details->getProviderState(); // e.g. reason=missing_api_key
$error = $details->getErrorMessage(); // redacted setup error, if any

OpenFeature (PHP 8, with open-feature/sdk installed):

require_once __DIR__ . '/vendor/autoload.php';

$api = \OpenFeature\OpenFeatureAPI::getInstance();
$api->setProvider(new \DDTrace\OpenFeature\DataDogProvider());
$flags = $api->getClient('checkout');
$layout = $flags->getStringValue(
    'checkout-layout',
    'control',
    new \OpenFeature\implementation\flags\EvaluationContext('user-123')
);

flowchart LR
    CDN[Managed or custom CDN] -->|HTTPS and ETag| Fetcher[libdatadog sidecar fetcher]
    Fetcher --> SHM[Shared memory]
    SHM --> Reader[PHP configuration reader]
    Reader --> Evaluate[Native and OpenFeature evaluation]
    Agent[Datadog Agent] --> RC[Per-thread Remote Configuration] --> Evaluate

Loading

[datadog-prod-us1-4]

 

✨ Unblock PR with BitsAI

❌ Errors

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

🚦 33 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-php | merge-gate — 🔧 Needs a code fix, caused by this PR

View more details · View in GitLab

DataDog/apm-reliability/dd-trace-php | test early PHP 8.1 — 🔧 Needs a code fix, caused by this PR

View more details · View in GitLab

DataDog/apm-reliability/dd-trace-php | test_extension_ci: [7.2, valgrind] — 🔧 Needs a code fix, caused by this PR

View more details · View in GitLab

View all 33 failed jobs.

⚠️ Warnings

⌛ 2 Test performance regressions detected

Test	New execution time	Base Execution time	Increase	DataDog link
tmp/build_extension/tests/ext/pcntl/pcntl_fork_thread_mode_orphan_telemetry.phpt (Thread mode: a fork child orphaned by its parent's exit replays its application on the connection to its own new listener) from php.tmp.build_extension.tests.ext.pcntl	10.41s	661.267577ms	+9.75s (+1475%)	View in Datadog
tmp/build_extension/tests/ext/pcntl/pcntl_fork_thread_mode_orphan_telemetry.phpt (Thread mode: a fork child orphaned by its parent's exit replays its application on the connection to its own new listener) from PHP.tmp.build_extension.tests.ext.pcntl	10.39s	672.862766ms	+9.71s (+1444%)	View in Datadog

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 68.39% (-0.01%)

Useful? React with 👍 / 👎

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

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2026-10-22 17:40:05

Comparing candidate commit 3c45358 in PR branch leo.romanovsky/php-agentless-cdn-20261013 with baseline commit cdadd1f in branch master.

📊 Benchmarking dashboard

Found 2 performance improvements and 0 performance regressions! Performance is the same for 191 metrics, 1 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:TraceFlushBench/benchFlushTrace

• 🟩 execution_time [-16.952µs; -7.448µs] or [-5.914%; -2.598%]

scenario:TraceFlushBench/benchFlushTrace-opcache

• 🟩 execution_time [-14.256µs; -7.444µs] or [-4.715%; -2.462%]

Unstable benchmarks

These benchmarks have a confidence interval too wide to call a change; treat them as noise rather than signal.

scenario:LaravelBench/benchLaravelDdprof-opcache

• unstable execution_time [-456.797µs; +898.877µs] or [-3.481%; +6.849%]

[bwoebi]

Please don't introduce external I/O in the PHP processes. That's the sidecars task.
Intuitively, I'd reach for the same delivery between tracer and sidecar as RC though - i.e. splice it in into ShmRemoteConfig.
Also the fetching logic/transport should be part of libdd-ffe crate, then at least Python could reuse that as is.