Loading feature flags from new endpoint by linglingye001 · Pull Request #738 · Azure/AppConfiguration-DotnetProvider

linglingye001 · 2026-06-12T09:04:19Z

Previously, feature flags were loaded only as classic key-values prefixed with .appconfig.featureflag/. This PR registers a parallel "new feature flag" selector/watcher for each FeatureFlagSelector, fetches flags via the dedicated SDK endpoint, and synthesizes them back into the feature-management JSON schema so downstream parsing is unchanged. Classic flags can be turned off via a new opt-in flag ExcludeClassicFeatureFlags.

Changes:

Add opt-in behavior to exclude classic feature flags and prefer the new feature-flag endpoint as the source of truth.
Introduce “new feature-flag selector/watcher” markers and update selector equality/hash behavior accordingly.
Implement loading + change detection for the new feature-flag endpoint, including synthesis into the existing feature-management JSON schema.

Copilot

Pull request overview

This PR adds support for loading feature flags from Azure App Configuration’s newer feature-flag endpoint and introduces an option to exclude “classic” feature flags stored under the .appconfig.featureflag/ key namespace.

Changes:

Add opt-in behavior to exclude classic feature flags and prefer the new feature-flag endpoint as the source of truth.
Introduce “new feature-flag selector/watcher” markers and update selector equality/hash behavior accordingly.
Implement loading + change detection for the new feature-flag endpoint, including synthesis into the existing feature-management JSON schema.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/Microsoft.Extensions.Configuration.AzureAppConfiguration/Models/KeyValueWatcher.cs	Adds a flag to distinguish watchers targeting the new feature-flag endpoint.
src/Microsoft.Extensions.Configuration.AzureAppConfiguration/Models/KeyValueSelector.cs	Adds a flag to distinguish selectors for the new endpoint and updates equality/hash logic.
src/Microsoft.Extensions.Configuration.AzureAppConfiguration/FeatureManagement/FeatureFlagSettingConverter.cs	New converter that synthesizes `ConfigurationSetting` instances from SDK `FeatureFlag` models using the existing feature-management JSON schema.
src/Microsoft.Extensions.Configuration.AzureAppConfiguration/FeatureManagement/FeatureFlagOptions.cs	Adds a new public option to exclude classic feature flags.
src/Microsoft.Extensions.Configuration.AzureAppConfiguration/Extensions/ConfigurationClientExtensions.cs	Adds change detection for the new feature-flag endpoint by comparing page ETags.
src/Microsoft.Extensions.Configuration.AzureAppConfiguration/AzureAppConfigurationProvider.cs	Routes loading/refresh logic between classic key-values and the new feature-flag endpoint; ensures new flags win on key conflicts.
src/Microsoft.Extensions.Configuration.AzureAppConfiguration/AzureAppConfigurationOptions.cs	Updates `UseFeatureFlags` to register new-endpoint selectors/watchers (and optionally omit classic flags); changes default SDK service version.

+                // The new endpoint uses null to mean "any name". A bare "*" is equivalent.
+                if (string.IsNullOrEmpty(nameFilter) || nameFilter == "*")
+                {
+                    nameFilter = null;
+                }


        private static ConfigurationClientOptions GetDefaultClientOptions()
        {
-            var clientOptions = new ConfigurationClientOptions(ConfigurationClientOptions.ServiceVersion.V2023_11_01);
+            var clientOptions = new ConfigurationClientOptions(ConfigurationClientOptions.ServiceVersion.V2026_05_01_Preview);
            clientOptions.Retry.MaxRetries = MaxRetries;


+        /// <summary>
+        /// When set to true, classic feature flags (key-values whose key is prefixed with
+        /// ".appconfig.featureflag/") are not loaded from the configuration store. Only feature flags
+        /// returned by the new feature-flag endpoint will be loaded.
+        /// Defaults to false; classic flags are loaded alongside new flags for backward compatibility.
+        /// </summary>
+        public bool ExcludeClassicFeatureFlags { get; set; } = false;


jimmyca15 · 2026-06-24T23:49:28Z

+
+                    foreach (SdkFeatureFlag ff in page.Values)
+                    {
+                        ConfigurationSetting synthesized = FeatureFlagSettingConverter.ToConfigurationSetting(ff);


The new feature flags shouldn't be converted to configuration setting. When we load a new feature flag, we should break it down into it's associated key-value pairs, like the feature flag adapter does for classic feature flags, and inject that into the configuration directly.

I saw some updates in the PR. Is this one still being worked on?

Yes, working in progess

Updated, new feature flags now map to the internal model (provider FeatureFlag) and share the ff adapter's logic.

jimmyca15 · 2026-06-25T00:07:34Z

This needs to go into the preview branch.

…mit logic

jimmyca15 · 2026-07-01T21:03:14Z

+        /// configured <see cref="ClientOptions"/> so that the feature-flag client communicates with the
+        /// same store, audience, transport and retry behavior as the configuration client.
+        /// </summary>
+        internal FeatureFlagClientOptions GetFeatureFlagClientOptions()


If we're going to separate the options, I think it will be better to have FeatureFlagClientOptions as a property just like ClientOptions.

And whenever ConfigureClientOptions is used, we can reflect the changes on FeatureFlagClientOptions.

Makes consumption equal.

jimmyca15 · 2026-07-01T21:07:51Z

+
+namespace Microsoft.Extensions.Configuration.AzureAppConfiguration
+{
+    internal class ClientWrapper


How about we introduce IAppConfigurationClient which exposes the methods that we need to use from both FeatureFlagClient and ConfigurationClient. And the implementation AppConfigurationClient can contain both internally.

That way the provider can still work with a single client.

jimmyca15 · 2026-07-01T21:14:29Z

+            // Emit configuration for feature flags loaded from the standalone feature-flag endpoint.
+            // These are mapped directly from the SDK model to feature-management key-values without
+            // round-tripping through a synthesized ConfigurationSetting.
+            if (sdkFFs != null && sdkFFs.Count > 0)


I think that there should be a separate method to add feature flags into data.

private void ProcessFeatureFlags( Dictionary<string, ConfigurationSetting> data, IEnumerable<FeatureFlag> featureFlags);

jimmyca15 · 2026-07-01T21:15:35Z

-                        if (key.StartsWith(prefix, StringComparison.OrdinalIgnoreCase))
+                        SdkFeatureFlag featureFlag = kvp.Value;
+
+                        FeatureManagement.FeatureFlag model = SdkFeatureFlagModelMapper.MapToModel(featureFlag);


There shouldn't be an intermediate state. We should go straight from FeatureFlag to the IEnumerable<KeyValuePair<string, string>> that should go into configuration.

jimmyca15 · 2026-07-01T21:17:10Z

+using Azure;
+using Azure.Data.AppConfiguration;
+using Microsoft.Extensions.Configuration.AzureAppConfiguration.Models;
+using SdkFeatureFlag = Azure.Data.AppConfiguration.FeatureFlag;


Let's avoid introducing this concept of 'SdkFeatureFlag'.

Going forward 'FeatureFlag' refers to the new flags.

All previous naming for old flags should be renamed to ClassicFeatureFlag. Including the type here.

If we do need some separation, we can use the terms classic feature flag and standalone feature flag.

jimmyca15 · 2026-07-01T21:32:22Z

            return data;
        }

+        private async Task LoadFeatureFlags(


I'd like to keep classic feature flags and standalone feature flags separate.

…ugrationClient

linglingye001 requested a review from Copilot June 12, 2026 09:04

Copilot started reviewing on behalf of linglingye001 June 12, 2026 09:05 View session

Copilot AI reviewed Jun 12, 2026

View reviewed changes

linglingye001 marked this pull request as ready for review June 23, 2026 01:23

linglingye001 changed the title ~~Exclude classic feature flags~~ Loading feature flags from new endpoint Jun 23, 2026

jimmyca15 reviewed Jun 24, 2026

View reviewed changes

Comment thread src/Microsoft.Extensions.Configuration.AzureAppConfiguration/AzureAppConfigurationOptions.cs Outdated

jimmyca15 reviewed Jun 24, 2026

View reviewed changes

linglingye001 and others added 5 commits June 25, 2026 10:16

add null check in examples (#732)

fb55fda

rebase

31970ca

update

5b86a9d

update

c1702c5

wip

56f906e

linglingye001 force-pushed the linglingye/exclude-classic-ff branch from 708b5b1 to 56f906e Compare June 25, 2026 09:50

zhiyuanliang-ms changed the base branch from main to preview June 25, 2026 09:58

jimmyca15 reviewed Jun 25, 2026

View reviewed changes

Comment thread src/Microsoft.Extensions.Configuration.AzureAppConfiguration/AzureAppConfigurationProvider.cs Outdated

linglingye001 added 5 commits June 26, 2026 17:06

map SDK feature flags to the internal model and share the adapter's e…

4838391

…mit logic

update

e705b09

use dedicated FeatureFlagClient

f7718bf

update

3112565

update

c01c38d

jimmyca15 reviewed Jul 1, 2026

View reviewed changes

linglingye001 added 2 commits July 2, 2026 22:05

resolve comments, separate classic ff and new ff, introduce IAppConfi…

64bdf4a

…ugrationClient

update

eb27742

Uh oh!

Conversation

linglingye001 commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jimmyca15 commented Jun 25, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

linglingye001 commented Jun 12, 2026 •

edited

Loading