FeatureFlagChangeListener doesn't get triggered when changing to an user with a different flag value

[anawu2006]

Is this a support request? No

Describe the bug We recently upgraded LaunchDarkly SDK from 2.11.0 to 3.1.1 and noticed that in SDK 3.1.1 the FeatureFlagChangeListener doesn't get triggered when user is changed and the values of same flag are different for different users.

To reproduce

1. init to user1 with LDClient.init(context, config, user1).
2. switch to user2 with LDClient.identify(user2).
3. switch back to user1 with LDClient.identify(user1). (so far app has cached flags values for both users).
4. register listener for flagKeyA with LDClient.registerFeatureFlagListener(flagKeyA, listener). listener.onFeatureFlagChange will be invoked when user1's flagKeyA value gets changed in LaunchDarkly dashboard.
5. switch to user2 with LDClient.identify(user2). For same flag flagKeyA, the values of user1 and user2 are different.
6. listener.onFeatureFlagChange doesn't get invoked.

Expected behavior listener.onFeatureFlagChange should be invoked.

Logs None

SDK version 3.1.1

Language version, developer tools Android Kotlin

OS/platform Android API 31

Additional context I have checked the source code of SharedPrefsFlagStore.clearAndApplyFlagUpdates and noticed that listener doesn't get triggered since the value of user2 is same as the cached value of user2. But FeatureFlagChangeListener is for a specific flag, not for a flag of a specific user. Thus I think this is a bug.

[louis-launchdarkly]

Hello @anawu2006, while the current document for 2.x and 3.x states the FeatureFlagChangeListener only trigger when a feature flag value has changed for the current user, we understand having FeatureFlagChangeListener trigger when user change causes flag change can potentially be useful and we will need to discuss this feature internally. We will provide another update after the discussion.

[anawu2006]

@louis-launchdarkly I see. Thank you so much for the explanation!

[louis-launchdarkly]

@anawu2006 After discussing this with the team, we think this is an enhancement that will make the FeatureFlagChangeListener more intuitive to use. We will file this on our backlog and keep this issue open.

Filed internally as 132307

[anawu2006]

@louis-launchdarkly cool! Thanks for letting me know!

[ronnyremesnik]

@louis-launchdarkly @anawu2006

I have a very similar problem and I was going to write it, and I saw this ticket, so I will write it here.

We have an app that registers many flag listeners at the initialization level. Once user 1 is identified with some custom field, like project_id with value of Project_1, the FeatureFlagChangeListener is called and the app gets the updated values but once We identify user1 with a different custom field value of project_id for example Project_2 and go back and identify again user1 with custom field value Project_1 the FeatureFlagChangeListener is not called and our app stays with the old and wrong value of the flag for the custom field value ...

Looks like FeatureFlagChangeListener should be triggered each time custom fields value changes...

Is it the same issue or it's something new ?

Do we have ETA when this enhancement will be available? Thanks...

SDK version 3.1.0

[ronnyremesnik]

@louis-launchdarkly Hey, What do you think about my last comment ? Thanks in advance

[louis-launchdarkly]

@ronnyremesnik We think what you described is the same issue - once we do the enhancement, the FeatureFlagChangeListener should be called when identify changes the flag value.

[anawu2006]

@ronnyremesnik two solutions I have tried to walk around this for your reference:

1. register a new FeatureFlagChangeListener once user changed.
2. set maxCachedUsers of LDConfig as 0.

[ronnyremesnik]

@anawu2006 Thank you, 1 worked!

[groeneman]

I'm having a similar issue where flags don't update after a call to identify, but I couldn't get @anawu2006 's option 1 above to work, at least by calling something like:

val identify = client.identify(context)
client.unregisterFeatureFlagListener(flagKey, listener)
client.registerFeatureFlagListener(flagKey, listener)

I ended up blocking until flags updated, like this:

val identifyComplete = client.identify(context)

try {
    identifyComplete.get(2L, TimeUnit.SECONDS)
} catch (ex: TimeoutException) {
    Timber.e("Post-identify LaunchDarkly update timed out")
}

listener.onFeatureFlagChange(flagKey)

Which is much less elegant! Maybe I missed something in my attempt at the first approach? Any tips would be appreciated!

[tanderson-ld]

This issue should now be fixed in version 4.2.3.