Let applications record feature flag exposures with ExposureHook

[danyal002]

Warning

NOT READY FOR REVIEW YET

Stacked on #12774. Includes the commits of #12772 until it merges.

What Does This Do

• Adds a public ExposureHook. It hands each completed evaluation to a callback, with the provider's exposure decision:
  • shouldSend() is true for exactly the exposures the provider sends to Datadog.
  • isExposure() is true for every successful evaluation of an allocation that logs exposures, including repeats. getCacheHit() tells repeats apart.
  • getFeatures() returns the selected split's features whose destinations include HOOK, such as holdout.key and holdout.assignment_group.
• A destination the SDK does not know is ignored, with one warning for each new name.
• Copies the selected split's features into the flag metadata as __dd_feature.<key>.
• Adds DD_FEATURE_FLAGS_EXPOSURES_DATADOG_LOGGING_ENABLED (default true). When false, the provider sends no exposures to Datadog. The exposure cache keeps running, so ExposureHook callbacks get the same decisions.
• Documents the contract in the dd-openfeature README.

Motivation

Some customers use Datadog feature flags but keep exposures in their own data store. They need each exposure, with the holdout key and assignment group, in their own code. They also need to stop sending the same exposures to Datadog.

Additional Notes

• The callback runs on the evaluation thread. The README tells customers to hand data to a background queue.
• With an older dd-java-agent, the split has no features, so getFeatures() is empty. Exposure decisions still work.
• The new setting is registered in metadata/supported-configurations.json.

Jira ticket: EX-3815 [EX-3801]

[datadog-prod-us1-4]

🎯 Code Coverage (details)
• Patch Coverage: 87.32%
• Overall Coverage: 59.31%

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

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	13.94 s	13.89 s	[-0.7%; +1.3%] (no difference)
startup:insecure-bank:tracing:Agent	12.91 s	12.96 s	[-1.1%; +0.3%] (no difference)
startup:petclinic:appsec:Agent	17.16 s	17.06 s	[-0.3%; +1.5%] (no difference)
startup:petclinic:iast:Agent	17.01 s	17.06 s	[-1.1%; +0.5%] (no difference)
startup:petclinic:profiling:Agent	16.69 s	16.79 s	[-1.7%; +0.5%] (no difference)
startup:petclinic:sca:Agent	17.02 s	16.94 s	[-0.4%; +1.4%] (no difference)
startup:petclinic:tracing:Agent	16.24 s	16.16 s	[-0.7%; +1.7%] (no difference)

Commit: 296c9890 · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.