Harden Agentless Feature Flags EVP delivery - #12200
Conversation
…ures EVP
FeatureFlagEvpContext.from builds the top-level context map shared by both
the flagevaluation and exposures EVP writers. Add source.name ("dd-trace-java")
and source.version (TracerVersion.TRACER_VERSION) so the SDK identity facets
are populated on both EVP streams. This closes the gap noted in the Feature
Flag Observability Telemetry Roadmap where the Java server SDK emitted no
SDK/tracer name or version on the flag_evaluations EVP stream.
Co-Authored-By: Claude <noreply@anthropic.com>
This comment has been minimized.
This comment has been minimized.
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
…ntext
The flagevaluation track schema (logs-backend flagevaluation.conf) declares
source.name/source.version as top-level per-event fields, siblings of
flag/variant/targeting_key. The previous implementation put them in the
batch context envelope alongside service/env/version, which the EVP indexer
maps to context.source.* — an undeclared facet that causes the indexer to
drop the entire event.
Move source to the FlagEvaluationEvent top level (as a nested source object
{name,version}) so it lands on the declared source.name/source.version
facets. Verified end-to-end via ffe-dogfooding against staging: Java
flagevaluation events now index in the staging flag_evaluations data source.
Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
Generated with Claude Code
Generated with Claude Code
Generated with Claude Code
Generated with Claude Code
Send SDK identity headers on both flag evaluation and exposure requests while preserving them across proxy-to-direct fallback. Keep the BackendApi request signature unchanged by configuring headers on feature-flag backend instances.\n\nGenerated with Claude Code
Scope the SDK identity headers to feature-flag HTTP clients so both evaluation and exposure requests retain them across proxy and direct intake without modifying transport implementations.\n\nGenerated with Claude Code
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep it up! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
…-name-and-version-java # Conflicts: # communication/src/main/java/datadog/communication/BackendApiFactory.java
Move the DD-EVP-ORIGIN and DD-EVP-ORIGIN-VERSION header names and the dd-trace-java origin value into EvpProxy, next to the existing subdomain header constant. ProfileUploader and CrashUploader already declare private copies of these names, so the feature-flagging code used string literals as a third copy. Replace the FeatureFlagBackendApiFactory test that asserted the contents of the REQUEST_HEADERS map, which restated the implementation and would pass even if the headers never reached the wire. The field is private again. Cover both transports with MockWebServer assertions instead. The direct intake test uses followRedirects=false to match the feature-flagging caller, so it also covers the redirect-scoped client wrapped by the header interceptor. Removing the interceptor from the direct intake path makes the new test fail. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The subdomain and Accept-Encoding assertions were added by this branch to a pre-existing test that only checked the request path. Neither relates to SDK identity headers, which evpProxySendsConfiguredRequestHeaders now covers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Share Agentless route state across event writers, preserve Agent prefixes, capability-gate local forwarding, and cover deterministic send-once failover behavior. Environment: Datadog workspace
|
Superseded by #12477, which carries the same final SDK identity plus Agentless EVP hardening diff as one signed commit directly on the current master SHA. This avoids reviewing the unrelated files exposed by the old branch's merge history; no remote history was rewritten. |
There was a problem hiding this comment.
More details
The change keeps the JSON payloads unchanged. It applies the SDK identity headers to both delivery paths without a reportable defect.
🤖 Datadog Autotest · Commit f1a7696 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
Motivation
We are shipping an agentless, CDN-delivered Feature Flags configuration mode to make customer deployments simpler. Configuration polling is only half of that product path: the exposures and flag-evaluation telemetry produced by the SDK also needs a reliable network path out of the process.
Java therefore needs to auto-discover a compatible local Agent or serverless proxy and fall back to the canonical direct EVP intake when no safe local route exists. That fallback must not duplicate a batch after an ambiguous network failure, leak the API key to a local process, or change the historical Remote Config/Agent-only transport.
This expands the original SDK-identity change into the cohesive Java transport required by the cross-language Agentless EVP contract. Tracks FFLSDK-187 and preserves the FFL-3016 attribution goal.
Changes
DD-EVP-ORIGIN: dd-trace-javaandDD-EVP-ORIGIN-VERSION: TracerVersion.TRACER_VERSIONon both local and direct Feature Flags EVP requests./infoto advertise forwarding support for both SDK identity headers./info, trace probes, and EVP requests.https://event-platform-intake.<site>/api/v2/{event}with redirects and generic HTTP retries disabled.ConnectException. Other local failures switch only future batches when direct intake is available.Decisions
/evp_proxy/v2without/infodiscovery or direct credentials; a later flush uses that same fixed route after a failure.X-Datadog-EVP-Subdomainremains local-only. SDK identity is present on both routes.Validation
Base SHA:
3110972ccf744f304a7cf59973e240f9ccd1a071Candidate SHA:
f1a76966057cb7bf0d9921a8731d016a20fe7575All commands passed locally:
Added wire/unit coverage for:
No manual system-tests or dogfooding run was claimed for this exact candidate SHA. Those repositories were intentionally left unchanged for this SDK-only PR; the PR's existing system-test workflow is the end-to-end gate.