Send feature flag SDK identity in request headers - #12200
Draft
vjfridge wants to merge 10 commits into
Draft
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>
vjfridge
added
tag: ai generated
This comment has been minimized.
This comment has been minimized.
Contributor
🟢 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
vjfridge
changed the title
Generated with Claude Code
vjfridge
changed the title
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
vjfridge
changed the title
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
Contributor
Author
|
@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". |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Send Java SDK identity as request metadata on both
flagevaluationandexposuresEVP requests while keeping their JSON payloads unchanged.DD-EVP-ORIGIN: dd-trace-javaDD-EVP-ORIGIN-VERSION: TracerVersion.TRACER_VERSIONChange
BackendApiFactory.BackendApi,EvpProxyApi, andIntakeApirequest APIs unchanged.sourcepayload approach, which is incompatible with the deployed strict payload schema.Testing
./gradlew :communication:clean :communication:test :communication:jacocoTestCoverageVerification -PtestJvm=8 -PcheckCoverage./gradlew :products:feature-flagging:feature-flagging-lib:clean :products:feature-flagging:feature-flagging-lib:test -PtestJvm=8 -PcheckCoverage./gradlew :communication:spotlessCheck :products:feature-flagging:feature-flagging-lib:spotlessCheckImplements FFL-3016.