Send feature flag exposures only after a successful evaluation

[danyal002]

Warning

NOT READY FOR REVIEW YET

What Does This Do

• Moves exposure sending from flag resolution to a new provider hook, ExposureLoggingHook, that runs at the OpenFeature finally stage.
• Adds a provider exposure cache, ExposureDeduplicationCache, keyed on (flag, subject). Resolution only checks it, and stamps __dd_exposure_cache_hit in the flag metadata.
• The hook records the exposure and sends it when:
  • the allocation logs exposures,
  • the subject is not already exposed with the same allocation, variant and serial id, and
  • the evaluation has no error.
• When an allocation logs exposures, the flag metadata now always carries __dd_do_log and __dd_split_serial_id, not only when span enrichment is on.

Motivation

Today the provider sends the exposure while it resolves the flag, before any hook runs. OpenFeature runs provider hooks first, so an application after hook can still throw and give the application the default value. The exposure was already sent in that case. At the finally stage the result is final, so a failed evaluation sends nothing and the next evaluation sends the exposure.

The provider cache is also the base for a customer exposure hook in a later change, so that Datadog and the customer use the same exposure decision.

Additional Notes

• The agent's exposure writer keeps its own cache. The provider (dd-openfeature) and the agent (dd-java-agent) ship separately, and an older provider still sends every evaluation. The provider cache has the same size as the writer's cache (65,536 entries), so both drop the same repeats. The writer's cache will be removed after the feature-flagging code moves out of dd-java-agent.
• Exposures are sent only through an OpenFeature client. Calling Provider evaluation methods directly runs no hooks, so it sends no exposures.

Jira ticket: EX-3800

[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	14.01 s	13.85 s	[+0.4%; +1.9%] (maybe worse)
startup:insecure-bank:tracing:Agent	12.94 s	12.92 s	[-0.5%; +0.8%] (no difference)
startup:petclinic:appsec:Agent	17.05 s	16.45 s	[-0.9%; +8.1%] (no difference)
startup:petclinic:iast:Agent	16.26 s	16.93 s	[-8.2%; +0.2%] (no difference)
startup:petclinic:profiling:Agent	16.47 s	16.67 s	[-2.3%; -0.1%] (maybe better)
startup:petclinic:sca:Agent	16.96 s	16.83 s	[-0.3%; +1.7%] (no difference)
startup:petclinic:tracing:Agent	15.73 s	16.15 s	[-6.8%; +1.6%] (no difference)

Commit: e43b49a9 · 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.