Cached flags are not persisted correctly

[eric-klukovich]

The LaunchDarkly library caches fetched feature flags locally so they are known if the servers cannot be reached. We are encountering an issue where the cached flags are "cleared" when we load up the app offline after a Google Play store update.

We were able to track down the issue in the SDK code, and it appears that the DefaultUserManager uses a hashed value of the LDUser json string, which includes all fields. We created a LDUser using the builder code below, where the "version_code" gets updated after the release and causes the DefaultUserManager to create a new cache file instead of using the original one.

Is there a work-around where we can specify the LDUser cache name specifically, so it will not be impacted by any properties that have a dynamic value? Ideally, having the userId as the cache name would work for our use case.

val builder = LDUser.Builder(userId)
            .email(userEmailAddress)
            .firstName(userFirstName)
            .lastName(userLastName)
            .custom("company_id", companyId)
            .custom("project_id", projectId)
            .custom("version_code", appVersionCode)

We believe this method in the DefaultUserManager class is causing our issue:

public static String sharedPrefs(final LDUser user) {
     return HASHER.hash(toJson(user));
}

To reproduce

1. Create a LDUser that a property that can change
2. Get the current flags
3. Change the property to another value
4. Flags will not longer be cached

SDK version
3.1.2

Language version, developer tools
Kotlin 1.5.31

OS/platform
Android - All OS versions

[vorobyov-denis]

Looks like the issue I posted half an hour ago 😄

[maxkohne]

We are experiencing the same thing. What a coincidence you posted about it around the same time!

[vorobyov-denis]

It's amazing! Given that this bug has been present since version 2.0.4

[louis-launchdarkly]

Hello @eric-klukovich, @vorobyov-denis, @maxkohne, thank you for reaching out.

Just to clarify, is there a reason that the version_code is part of the User construction? Because you can target user using custom attribute, when a custom value changes, the SDK will need to get the flags again because the actual flag value can change. And from the Android Client-side SDK perspective, the SDK cannot tell even if you have no rules referring to the version_code.

@vorobyov-denis, I will reply to your issue separately - because if your User object didn't change, that seems to be a different issue compared to this one.

[eric-klukovich]

Hi @louis-launchdarkly!

We have the version_code as a custom attribute because we use it to target a flag specific app versions. For instance we want to turn on a feature for apps after a specific version. We are using the custom attributes to target specific users:

The issue that that we are facing is that the LDClient creates a user flag cache name from the hashed JSON string created from LDUser model, including custom properties. In our case project_id and company_id are also dynamic so we would encounter this issue with those as well.

Here is an example of the LDUser JSON string:

{
  "firstName": "test_first_name",
  "lastName": "test_last_name",
  "key": "123456",
  "email": "test_email@test.com",
  "custom": {
    "version_code": 1,
    "company_id": "123",
    "os": 30,
    "project_id": "456",
    "device": "SM-G973U1 beyond1qlteue"
    }
}

Any time one of the custom property values change, then the hash code for this LDUser will differ and causing a new cache file to be created for the same user.

[louis-launchdarkly]

@eric-klukovich Thank you for clarifying. As described in your case, we know that is the same person behind the android device. However, if we reuse the old cache file, wouldn't the user potentially get incorrect flags? Or are you asking for something that can selectively update some cache entries but reuse the same cache file key? Note, the SDK will still need to fetch all flags even if we could replace some entries in the cache, so this will not save any time.

If your exact concern is the number of cache files (i.e. the SDK is creating too many cache files and is taking up unnecessary space), you could use the maxCachedUsers setting in the Config to reduce the number of cache files. https://javadoc.io/doc/com.launchdarkly/launchdarkly-android-client-sdk/latest/com/launchdarkly/sdk/android/LDConfig.Builder.html - The default is 5.

[eric-klukovich]

I'm asking for something to reuse the same cache file key, but the flags continue to be updated properly.

We are trying to solve an edge-case where the user has updated the app (version code changes) but the device is offline when they open the app. Since they are offline, no flags will be fetched from LD and they go to the default state. It would be better if the flags can use the last cached version of the flags instead.

[louis-launchdarkly]

Hello @eric-klukovich, thank you for being patient with me. Now I understand your case exactly - the cache key changed but there is no way to fetch new information (the app is offline) so the code gets the default. I will need to check how the caching refresh logic works and discuss it with the team before we can decide what is the next step. I will give an update once we looked into this.

Filed Internally as 142147.

[eric-klukovich]

Great! Thank you for the quick response! 😃

[eric-klukovich]

Hi @louis-launchdarkly, are there any updates on this?

[maxkohne]

@louis-launchdarkly Can we get a status update on this issue please?