feat(feature-flags): wire source-agnostic activation and OpenFeature InitializeAsync - #9044
Conversation
BenchmarksBenchmark execution time: 2026-09-14 07:31:31 Comparing candidate commit 41092bc in PR branch Found 0 performance improvements and 1 performance regressions! Performance is the same for 71 metrics, 0 unstable metrics, 68 known flaky benchmarks, 58 flaky benchmarks without significant changes.
|
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (9044) and master. ✅ No regressions detected |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 613a808d7d
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
…lformed sites safely
…nd validation telemetry
… sensitive in yaml
|
🤖 Comment from Claude working with Aaron Silverman:
Please add:
|
bouwkast
left a comment
There was a problem hiding this comment.
I have one main question on the Initialization logic
Feel free to re-request my review 👍
…o.khrebto/EX-2703/ffe-module-wiring
…9260) ## Summary of changes Removes `Datadog.Trace.FeatureFlags.FeatureFlagsSdk`, the manual non-OpenFeature Feature Flags API, from `Datadog.Trace.Manual`, along with its three CallTargets and its test sample. OpenFeature (`Datadog.FeatureFlags.OpenFeature`) becomes the only way to evaluate flags in .NET. ## Reason for change .NET was the only tracer with a second, Datadog-specific evaluation surface — Java, Go and Node ship OpenFeature only. If OpenFeature is the intended supported approach, the duplicate is better removed now, while Feature Flags is experimental and gated behind `DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED`, than after customers adopt it. The surface shipped in v3.36.0 (#7896). It is undocumented and excluded from the public API snapshot: `PublicApiTestsBase` skips types carrying both `[Browsable(false)]` and `[EditorBrowsable(Never)]`, so `FeatureFlagsSdk` appears nowhere in `PublicApiTests.Datadog.Trace.Manual.PublicApiHasNotChanged.verified.txt`. It also makes sense to remove it now while no customers use it. ## Implementation details Deleted: - `Datadog.Trace.Manual/FeatureFlags/` — `FeatureFlagsSdk`, `EvaluationContext`, `IEvaluation.Manual` - `ManualInstrumentation/FeatureFlags/` — the `Evaluate`, `IsAvailable` and `RegisterOnNewConfigEventHandler` CallTargets - the three `<Compile Include>` links in `Datadog.Trace.Manual.csproj` (`EvaluationReason`, `ValueType`, `IEvaluation`). `Datadog.FeatureFlags.OpenFeature.csproj` links its own copies straight from `Datadog.Trace` and is unaffected - the `Samples.FeatureFlags` project, with its `Datadog.Trace.sln` and CODEOWNERS entries `Program.cs` was shared by both samples through a `<Compile Include>` link, so it moves into `Samples.OpenFeature` and the link is dropped. Generated files regenerated with `CompileManagedSrc` and `RegenerateSolutions`. The diffs are pure deletions of the three rows, with no signature renumbering. ## Test coverage `FeatureFlagsTests`, `OpenFeatureFeatureFlagsTests` and `FeatureFlagsTestsBase` collapse into a single `FeatureFlagsTests` on the OpenFeature sample. Coverage of the manual surface goes away with the surface itself. Two sample-side improvements come with the move: - `Samples.OpenFeature`'s `Evaluator.Init()` awaits `SetProviderAsync` instead of calling `.Wait()` - a new `<INITIALIZED: READY>` probe and assertion — the only coverage of the OpenFeature `InitializeAsync` CallTarget merged in #9044 ## Other details Breaking change for anyone calling `Datadog.Trace.FeatureFlags.FeatureFlagsSdk` directly.
…ump the OpenFeature package (#9264) ## Summary of changes - `FeatureFlagsModule.RegisterOnNewConfigEventHandler` now invokes the handler immediately when a configuration is already held. - `Datadog.FeatureFlags.OpenFeature` package version 2.3.0 → 2.3.1. ## Reason for change The Remote Configuration subscription is live from module construction, which is tracer startup. Application code builds the provider and registers the configuration handler much later. The handler only fired on a change, so a configuration that arrived in that window never reached it, and an application that waits on the handler as its readiness signal waits forever. `Datadog.FeatureFlags.OpenFeature` 2.3.0 is already published on nuget.org and is immutable. The `InitializeAsync` fix in #9044 rewrites a method that lives in that package, so it cannot reach any customer until the package version moves. ## Implementation details Registration reads `_evaluator`. A non-null value means a configuration was applied, so the handler is invoked once at registration. The invoke is wrapped in a try/catch that logs a warning, matching `ApplyConfiguration`: the handler is application code and must not fail the caller. 2.3.1 follows the scheme documented in the csproj: the first two digits mirror the referenced OpenFeature version, the third digit is our own patch counter. The `OpenFeature` `PackageReference` stays at 2.3.0. ## Test coverage Three facts in `FeatureFlagsModuleTests`: the handler runs when it registers after a configuration was applied, it does not run when no configuration has arrived, and a throwing handler does not propagate out of registration. ## Other details Both changes address FFL-2468. The remaining half of that ticket, the `InitializeAsync` wait, is already on master via #9044. Together with this PR the next release carries the complete fix.
Summary of changes
Wires the agentless poller and RC subscription into
FeatureFlagsModulewith source-agnostic activation, and addsInitializeAsyncthrough the OpenFeature provider lifecycle so delivery starts when application code initializes the provider.This is PR 3 of a stacked PR series implementing agentless Feature Flags configuration delivery (FFL-2703), porting functionality from dd-trace-py#19331 and dd-trace-java#11892. Stacked on PR 1 #9040 and PR 2 #9042.
Reason for change
PR 1 added the configuration layer and PR 2 added the poller and parser. This PR connects them: the module now selects the delivery source at construction time, starts polling only when the provider is initialized, and waits for the first configuration before returning from
InitializeAsync.Implementation details
TracerSettings— replacesIsFlaggingProviderEnabledwithFeatureFlagsSettings FeatureFlagspropertyFeatureFlagsModule— source-agnostic constructor:Source == RemoteConfig(gated, no longer always-on)Create()checkssettings.FeatureFlags.EnabledActivate()starts the agentless poller or marks RC intent, with_deliveryStartedtrackingInitializeAsync()callsActivate(), waits forFirstConfigReceivedwith timeout, skips the wait if no delivery startedApplyConfiguration()— public method used by both agentless and RC paths, signalsFirstConfigReceivedDispose()now also disposes the agentless source and unsubscribes RCOpenFeatureSdkInitializeAsyncIntegration(new CallTarget) — interceptsFeatureFlagsSdk.InitializeAsyncstub and callsFeatureFlagsModule.InitializeAsyncDatadogProvider.InitializeAsync— override that delegates toFeatureFlagsSdk.InitializeAsyncFeatureFlagsSdk.InitializeAsync— no-op stub in the OpenFeature packagesupported_calltargets.g.json— registers the new integrationSpanEnrichmentIntegrationTests— suppresses[Obsolete]warning onFlaggingProviderEnabledTest coverage
FeatureFlagsModuleTests(9 tests) — RC config update/reset, agentless source doesn't subscribe to RC, RC source subscribes and advertises capability, disabled returns null,InitializeAsyncreturns immediately when config already applied, returns when config arrives while waiting, returns on timeout without throwing, returns on cancellation without throwing, returns immediately when agentless source cannot start (no API key)Other details
Stacked PRs:
System tests: DataDog/system-tests#7496