[BUG] Hashmap to Map Cast Exception in TargetingFilter.java when using Application Configuration #35823
Comments
github-actions
bot
added
azure-spring
noah-msft-brabec
changed the title
|
This appears to only be affecting us when we use a group or user override in a feature filter. If we have a simple feature flag that is only checking if the flag is on or off the check works. |
|
I've been doing a little more testing. So far I've only faced this bug when using the feature manager directly. The same casting error does not occur when using the |
|
I've been chatting with an internal resource and they directed me to the following workaround:
These two steps allowed the feature check to work for me again. |
|
Reverting to 4.7.0 should fix this for now if you are running into this issue. PR is up for a fix for this #35920. |
|
4.9.1 was released and fixes this issue. |
|
I am recieving following error java.lang.ClassCastException: class java.util.HashMap$Values cannot be cast to class java.util.Map (java.util.HashMap$Values and java.util.Map are in module java.base of loader 'bootstrap') I am using com.azure.spring:spring-cloud-azure-feature-management-web:5.3.0. and I am using spring boot 3.0.1 @component This is targetContext configuration I am using I am creating targeting filter bean @bean("Microsoft.Targeting") And just calling featureManager.isEnabledAsync("myfeature").block() it's giving above error when I try to execute featureManager.isEnabledAsync("myfeature").block() can you please help me resolve this? @mrm9084 |
|
The patch was never released for the 5.x versions. A new release should be out soon with the fix. @saragluna, we need to make sure this gets out. I saw the new 4.x versions going out yesterday. |
|
Targeting group filtering is also not working as expected. { This is my feature configuration in azure app config. public class TargetingContextAccessorImpl implements TargetingContextAccessor { } Here xyz is not part of group abc then How come feature is enabled for xyz. can you please address this issue? @mrm9084 |
In the example you gave, everyone will be part of the group "abc"? So it should alway return true? |
But xyz user is not part of abc group then why it's true for him? |
|
Am I missing something. You also hardcoded the userId to always be "xyz"? |
@component // ArrayList groups = new ArrayList(); Now I have added xyz in abc group and feature configuration is still same { I am recieving not enabled now ?? @mrm9084 |
|
@mrm9084 How featuremanagement sdk will verify if user is part of group or not ? |
|
|
|
This is a simple example as a POC, you should be able to replace @Component
@RequestScope
public class TargetingContextImpl implements TargetingContextAccessor {
@Autowired
private HttpServletRequest request;
@Override
public void configureTargetingContext(TargetingContext context) {
context.setUserId(request.getParameter("user"));
List<String> groups = new ArrayList<>();
groups.add(request.getParameter("group"));
context.setGroups(groups);
}
} |
|
So for groups we have to rely on AAD Token then right!! App configuration doesn't check the users group by itself dynamically right ? @mrm9084 |
|
That is correct. We didn't want to force any one direction. If you look at the dependencies of the library, it doesn't take dependencies on any azure service, not even App Configuration. |
|
Here is my feature configuration { Here how will the Rollout percentage work for abc group. I have 3 user xyz, efg and pqr in group abc. how will feature management lib will pick 50% rollout for these users. I am recieving flag disable for all users. Here is my context code @requestScope } |
|
@tejas097. First, You don't have three users in the group. Everyone single request is part of the group "abc" as you have hardcoded the group to always be abc. Second, you aren't setting a userid, so there is no difference between any two users. Third, this is a statistical 50% of users will be enabled/disabled. You need a large sample size to actually have it be 50%. We use the combination of UserId/Group/FeatureName to create a unique hash to put users into the different percentages. |
|
@tejas097, we have created the filters, but they are not enabled by default. You can do this by adding them to your |
@mrm9084 do we have to create percentage filter bean under Microsoft.Targetting ? or what should be the bean name for default rollout percentage like Microsoft.Targeting or Microsoft.TimeWindow something like that? |
|
The bean name should match the name of the feature filter. For example: @Bean(name = "Microsoft.TimeWindow")
public TimeWindowFilter timeWindowFilter() {
return new TimeWindowFilter();
}
@Bean(name = "Microsoft.Targeting")
@Scope("request")
public TargetingFilter targettingFilter(TargetingContextImpl context) {
return new TargetingFilter(context, new TargetingEvaluationOptions().setIgnoreCase(true));
} |
|
@mrm9084 percentage filter bean also part of Microsoft.Targeting or I will have to add some other bean name for percentage filter ? |
|
@tejas097, the name should follow the same format. Percentage filter isn't one provided by default in the App Configuration services anywhere, it still is in the provider though. The name should match the name you put for the filter in the feature flag. For example: {
"id": "Random",
"description": "",
"enabled": true,
"conditions": {
"client_filters": [
{
"name": "percentageFilter",
"parameters": {
"Value": 50
}
}
]
}
}In this case it would be Note: This filter is more of an example filter than anything else as it is pure random, generating a random number every request between 0 and 100 and returning true if the result is less than or equal to the |
How percentage filter is different from default percentage rollout percentage which app configuration provides under targeting filter ? |
|
If you run this for example 50 percent of the time it will be yes/no. It doesn't mater who/what is going on. It is just a 50/50 chance. For Targeting, if you have default percentage rollout set to 50, a statistical 50 percent of users will get true, the other 50 percent will get false. And they will always get those values. Another nice thing about Targeting is that if you change it from 50 to 60, all of the people that had true, will continue to get true. Just another 10% will get true also. |
|
@mrm9084 can azure sdk for feature management allow us to update feature flag if it has permission to do it ? and also can this sdk for feature management can give feature details what we have currently like what filter it has and other information regarding feature filter ? |
Describe the bug
When checking if a feature flag is enabled the exception
java.lang.ClassCastExceptionis thrown.Exception or Stack Trace
To Reproduce
Setup an http request or a piece of code that attempts to check if a feature flag is enabled. Make sure the feature flag has a feature filter with the default percentage set to 0% and an allowed group that is set to 100%. Running this code will cause the cast exception to fire.
Code Snippet
Here is my Java code that initiates the call to check if a flag is enabled:
Boolean.TRUE.equals(featureManager.isEnabledAsync("someFeatureFlag").block())This is the decompiled code that is throwing the exception from
TargetingFilter.java:The error is specifically thrown on this line when the default branch is taken:
exclusionAsLists.put(USERS, exclusionMap.getOrDefault(USERS, new HashMap<String, Object>()).values());Expected behavior
No cast exception is thrown, and that the feature flag check returns either a true or false.
Screenshots
Here is the state of the debugger right before the exception is thrown:
Setup (please complete the following information):
If you suspect a dependency version mismatch (e.g. you see
NoClassDefFoundError,NoSuchMethodErroror similar), please check out Troubleshoot dependency version conflict article first. If it doesn't provide solution for the problem, please provide:mvn dependency:tree -Dverbose)Additional context
I am using a remote configuration store. My local app is talking with a config store in the portal. It connects via a connection string.
Here are the related configured properties:
The config store has one key/value called
sentinelthat allows for dynamic refresh and one feature flag with a feature filter. Here is a screenshot of the details. The value pastTenant:is a guid: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
The text was updated successfully, but these errors were encountered: