Unable to get back a response from the backend where the feature is explicitly disabled

[StylianosGakis]

I got a feature flag, which makes sense to have it be default as true, so I fetch it with client.isEnabled("feature_id", defaultValue = true).
Now my problem is that I want the feature flag to come back from the backend explicitly as enabled = false when the feature flag is enabled, but I am not eligible for it due to one of my constraints.

What I experience instead is that when the flag is disabled in the unleash web client that I simply do not receive this flag at all.

I've confirmed this by using the in-memory cache for the flags and doing

        InMemoryToggleCache::class.java.getDeclaredField("internalCache").let { field ->
          field.isAccessible = true
          (field.get((hedvigUnleashClient.client.cache as InMemoryToggleCache)) as ConcurrentHashMap<String, Map<String, Toggle>>)
            .values
            .map {
              it.values
            }
            .joinToString(
                  prefix = "Feature:$feature | Unleash cache: ",
                  separator = ", ",
                  postfix = "",
              ) {
              "key:$it"
            }
        }

As a hack to read into the entire cache, and when the feature is on, I get in there something like Toggle(name=feature_id, enabled=true, variant=Variant(name=disabled, enabled=false, payload=null))
When I go to the unleash client and I set the rollout to 0% for example, as an easy one to test, what I see is that it's simply not there.

I may be missing something, but how would I be able to get back "Toggle(name=feature_id, enabled=false, variant=Variant(name=disabled, enabled=false, payload=null))" (emphasis on the bold false there) here instead?

Unleash version

5.9.0+main.3426.a4cd0771 (Pro)

Subscription type

Pro

Hosting type

Hosted by Unleash

SDK information (language and version)

0.5.7

[nunogois]

Hi @StylianosGakis, thanks for raising this issue. I believe this is working as intended as the unleash-android-proxy-sdk uses the frontend API, which only returns feature toggles that evaluate to true for the given context.

You can refer to: https://docs.getunleash.io/using-unleash/troubleshooting/flag-not-returned

Can you expand a bit on your use case and why you would want to see the disabled feature flag being returned?

[StylianosGakis]

I want a feature to be true by default, so failing to fetch the flag still results in the feature being enabled. And then I want to explicitly disable it for a specific set of people. So those specific people get the flag as false, and the feature is hidden for them.

[nunogois]

Hi @StylianosGakis, I believe what you're looking for is a kill switch instead. That way your feature is enabled by default, but if you switch the toggle to enabled, it disables the feature.

Basically what this means is:

• Create a kill switch feature toggle in Unleash;
• Implement it in your code by flipping the logic around - The feature should only be available when the kill switch is false;
• Add an activation strategy targeting the set of people that you want to disable the feature for;
• Turn the kill switch ON - It will be true for your targeted set of people, which means the feature will be available for everyone except that set of people.

I hope this helps!

[StylianosGakis]

Right, we do use a kill switch for another thing, and that has worked well for us, so that is great.

What I wonder then is if I want to gradually work on a feature, for some releases I have it off by default (for the offline case, really important to note this), and I turn it on conditionally, as normal flags work, all is good here.
Then on the new releases we decide that we want to flip this around after we have more confidence in the feature, but not 100% yet, and have it be true by default (so again, offline case where you can't fetch flags the feature is on now), then I want to still turn it off if something happens and I for example want to kill the feature if we've introduced a bug.

Is the verdict here that basically I can't reuse the same flag and I should introduce a new flag for that use case? Then for version X.X.X and lower I must remember that we use flag nbr1 and and for versions over X.X.X we use flag nbr2. And make sure that as I make that new release I stop checking the old flag and start using the new kill switch?

Am I understanding this right?

[kwasniew]

@StylianosGakis There's one more option where you can use strategy variants (https://docs.getunleash.io/reference/strategy-variants).

Here's one example (https://app.unleash-hosted.com/demo/projects/ipstrategies/features/always-enabled):

This flag is enabled in development for 100% of the users. But inside the single activation strategy you have 2 variants named enabled and disabled. This way you will always get a flag in your SDK and you can still set the % split for the variants. You only need to change your SDK to getVariant instead of isEnabled. Let me know if it solves your issue.

And more complex example:

Users of semver 4.5.1 get enabled variant and the remaining users get % split.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.