[vjfridge]

Description

Motivation

PHP emits flagevaluation track EVP events, but its current libdatadog
dependency does not attach the application's identity. This adopts merged
libdatadog #2716 so events
identify the right application and do not combine evaluations from different
applications. Implements FFL-3439
and follows PHP #4288.

Changes and key decisions

• Pin libdatadog to merged commit 3c17d86ddbbc2e4067b0a5680af38b5276810eb9;
  regenerate the required Cargo dependencies and C bindings.
• Keep PHP's per-evaluation application context empty. The sidecar supplies
  the application already registered on the connection, before aggregation.
• Attach service, environment, and application version to the batch, plus
  context.dd.service on ordinary events. Environment/version stay off the
  individual events; protected/degraded events retain their privacy rules.
• Verify default identity and identity changes before a single flush. Earlier
  evaluations keep their original identity, even when they use the same flag.
• Match the updated native debugger API: captured string size is now a number.
  Update PHP's assignment and the existing regression test accordingly.

Blast radius

• No new PHP setting, worker, queue, FFI call, or per-evaluation identity copy.
  Flag results, privacy rules, exposures, and SDK-origin headers keep their
  existing behavior.
• Compared with current PHP master, the native update also includes upstream
  debugger-size, OTLP resource-attribute, remote-config state, and regex-facade
  changes, plus the v48 release commit. The debugger change requires the small
  PHP compatibility adjustment above; this is more than an FFE-only update.
• Linux ARM64 validation covers FFE and shared debugger, remote-config,
  telemetry, and sidecar paths. Other supported platforms remain CI coverage.

Testing

Validated the source tree committed as
6ed17113c
against PHP master b89e238e4, using separately built local SDK artifacts.

• PHP 8.2 NTS / Linux ARM64: optimized builds pass on both branches;
  FFE/native/OpenFeature tests 34 pass, 3 skip and shared-path tests
  56 pass, 5 skip on each. Skips require other services, extensions,
  PHP versions, ZTS, or Windows.
• System-tests: all five FFE files forced on, 55/55 pass, versus
  51/55 on master. The four baseline failures lack application attribution.
  Absent/false/true consent pass, with protected payloads checked for raw PII.
• Stress accounting: both builds account for all 12,000 evaluations.
  Master delivered 11,955 + 45 reported drops; this branch delivered 11,846 +
  154 reported drops. This checks accounting, not equivalent performance or
  lossless delivery.
• ffe-dogfooding: native API and OpenFeature each ready; both builds emit
  36 evaluations and 36 OTel metrics, with identical flag responses.
  All new events have the expected service; origin remains dd-trace-php /
  1.27.0. Live consent was enabled; system-tests cover absent/false consent.
• Request reuse: eight evaluations across two persistent PHP servers retain
  the correct service/environment/version through identity changes and resets.

Frozen harnesses: system-tests 429e9e5
and ffe-dogfooding 2b662f8.

Remaining before merge

• Enable sidecar on 8.3 #2716 merged; adopt its merged commit and rerun validation.
• Supported-platform CI and reviewer approval.

Reviewer checklist

• Test coverage seems ok.
• Appropriate labels assigned.

[datadog-prod-us1-5]

 

⚠️ Warnings

Your PR has warnings. Please review the issues below.

🚦 4 Pipeline jobs failed

DDCI - DataDog/dd-trace-php | dsm-throughput

View more details · View in DDCI

DDCI - DataDog/dd-trace-php | publish docker image for system tests

View more details · View in DDCI

DataDog/apm-reliability/dd-trace-php | dsm-throughput

View more details · View in GitLab

View all 4 failed jobs.

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

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

Useful? React with 👍 / 👎

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

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2026-11-06 17:59:10

Comparing candidate commit 6ed1711 in PR branch vickie/FFL-3439/php-flagevaluation-application-identity with baseline commit b89e238 in branch master.

📊 Benchmarking dashboard

Found 0 performance improvements and 1 performance regressions! Performance is the same for 220 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:MessagePackSerializationBench/benchMessagePackSerialization

• 🟥 execution_time [+3.023µs; +3.877µs] or [+2.238%; +2.870%]

Unstable benchmarks

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

scenario:ComposerTelemetryBench/benchTelemetryParsing

• unstable execution_time [-1144.901ns; +344.901ns] or [-8.006%; +2.412%]