[BUG] Feature Management no longer working in 5.14.0

[alex-kuck]

Describe the bug After updating com.azure.spring:spring-cloud-azure-appconfiguration-config-web and com.azure.spring:spring-cloud-azure-feature-management-web from 5.13.0 to 5.14.0 the feature management using the Azure App Configuration is no longer working, i.e. always returning false for all features.

Exception or Stack Trace N/A

To Reproduce Update existing Spring Boot app to use 5.14.0 of Azure libraries

Code Snippet N/A

Expected behavior A minor version bump should work as before without requiring any configuration changes or similar.

Screenshots N/A

Setup (please complete the following information):

• OS: Linux/Docker
• IDE: IntelliJ
• Library/Libraries: implementation("com.azure.spring:spring-cloud-azure-appconfiguration-config-web:5.14.0") implementation("com.azure.spring:spring-cloud-azure-feature-management-web:5.14.0")
• Java version: 17
• Frameworks: Spring Boot 3.3.1

If you suspect a dependency version mismatch (e.g. you see NoClassDefFoundError, NoSuchMethodError or similar), please check out Troubleshoot dependency version conflict article first. If it doesn't provide solution for the problem, please provide:

• verbose dependency tree (mvn dependency:tree -Dverbose)
• exception message, full stack trace, and any available logs

Additional context Add any other context about the problem here.

bootstrap.yaml (working with 5.13.0):

spring.cloud.azure.appconfiguration:
  enabled: true
  stores:
    - connection-string: ${AZURE_APP_CONFIGURATION_CONNECTION_STRING:}
      monitoring:
        enabled: true
        triggers:
          - key: sentinel
        feature-flag-refresh-interval: 30s
      feature-flags:
        enabled: true
        selects:
          - label-filter: ',${AZURE_APP_CONFIGURATION_LABEL:}'

Information Checklist Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• [X] Bug Description Added
• [X] Repro Steps Added
• [X] Setup information Added

[github-actions[bot]]

@moarychan @netyyyy @rujche @saragluna

[github-actions[bot]]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[Netyyyy]

@mrm9084 please help take a look

[mrm9084]

@alex-kuck, do you use any filters in your feature flags? The only thing I could think of that changed in this version is adding support for Recurring Time Window filters, but that shouldn't have changed anything.

There are a couple reasons why a filter would just always return false, including it not being found. Could you check if you are actually getting them loaded into feature management? The easiest way to do that would be to call featuremanager.getAllFeatureNames(), it returns a Set<String> of all of the feature flag names that are currently loaded.

I'm trying to figure out if the issue is in the provider loading the feature flags or the feature management library accessing them.

[alex-kuck]

I just tried this and I think I found the issue. The call featuremanager.getAllFeatureNames() returns the expected set of feature names. The call featureManager.isEnabledAsync(<feature-key>).block() always returns false, however, when calling featureManager.isEnabledAsync(<feature-name>).block() the expected value true is returned. Is this an intentional change to query feature-flags by name instead of key? 🤔

Edit: Tried the same with 5.13.0 -> featuremanager.getAllFeatureNames() returns a set of feature keys instead of names.

[mrm9084]

By feature-name, do you mean id. That should have alway been the case. We recently switched the schema we use, I wonder if there was a bug fixed in the switch.

By default the feature-name should match feature-key, with the prefix removed.

[alex-kuck]

I have attached a screenshot of our Azure App Configuration. Starting with version 5.4.0 (version we first introduced) and every version since, we could check the state of the feature flag via the key following .appconfig.featureflag/, i.e. bypass-four-eyes-inspection and full-supply. Starting with 5.14.0 it seems it should be queried by Bypass 4-eyes inspection and Product Full Supply, i.e. the display name? Seems a bit counter-intuitive to me, I would expect to be able to update display names down the road without having to change some application logic.

Edit:

By default the feature-name should match feature-key, with the prefix removed.

If this is the case, then in my opinion it is bad practice to allow two separate inputs with differing contents.

[alex-kuck]

Any updates on this? Issue is also present in 5.15.0. Can I assist somehow?

[mrm9084]

@alex-kuck, this is working expected. These are the two schema we use with the feature management code: https://github.com/Azure/AppConfiguration/blob/main/docs/FeatureManagement/FeatureManagement.v2.0.0.schema.json https://github.com/Azure/AppConfiguration/blob/main/docs/FeatureManagement/FeatureFlag.v2.0.0.schema.json

The first one is the format of how we send groups of feature flags are read by the feature management library. The second is the schema for individual feature flags, which should also match what you see in the Azure Portal when you select Advanced Edit.

[alex-kuck]

This might be the case, but I can only repeat -> this schema was not used pre-5.14.0 and therefore is breaking existing applications in a minor version increment.

Additionally, the description from the Azure Portal - as seen in the screenshots - seems to be misleading -> the key is no longer accessible.