android-client-sdk icon indicating copy to clipboard operation
android-client-sdk copied to clipboard

NullPointerExeption thrown whenever we archive a flag

Open pal-tgiannakopoulos opened this issue 5 months ago • 4 comments

Is this a support request? No

Describe the bug

      Fatal Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.Object.hashCode()' on a null object reference
   at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
   at com.launchdarkly.sdk.android.ContextDataManager.notifyFlagListeners(ContextDataManager.java:317)
   at com.launchdarkly.sdk.android.ContextDataManager.initDataInternal(ContextDataManager.java:179)
   at com.launchdarkly.sdk.android.ContextDataManager.switchToContext(ContextDataManager.java:100)
   at com.launchdarkly.sdk.android.LDClient.identifyInternal(LDClient.java:427)
   at com.launchdarkly.sdk.android.LDClient.identifyInstances(LDClient.java:451)
   at com.launchdarkly.sdk.android.LDClient.identify(LDClient.java:399)

We are assuming that the following code inside ContextDataManager.java is causing a null element to end up in the updatedFlagKeys collections which is used as a parameter to notifyFlagListeners method.

        for (Flag newFlag: newData.values()) {
            Flag oldFlag = oldData.getFlag(newFlag.getKey());
            if (oldFlag == null || !oldFlag.getValue().equals(newFlag.getValue())) {
                // if the flag is new or the value has changed, notify.  This logic can be run if
                // the context changes, which can result in an evaluation change even if the version
                // of the flag stays the same.  You will notice this logic slightly differs from
                // upsert.  Upsert should only be calling to listeners if the value has changed,
                // but we left upsert alone out of fear of that we'd uncover bugs in customer code
                // if we added conditionals in upsert
                updatedFlagKeys.add(newFlag.getKey());
            }
        }

To reproduce We haven't managed to reproduce this on demand but we are seeing this crash whenever we are archiving a flag. In our app we allow logging out, which causes a call to identify with an anonymous context. Our assumption based on user flow logs is that this action is causing the crash to happen probably after a flag is archived.

Expected behavior To not crash

Logs No other logs related other than the crashlog in the description

SDK version Android SDK 5.3.0

Language version, developer tools Kotlin 1.9.24 Android compile SDK version 34 Android target SDK version 34 Gradle plugin version 8.5.0 Gradle version 8.8

OS/platform Android regardless of version Our app runs from Android 8 to Android 14 All of them seem to have the same problem

Additional context Add any other context about the problem here.

pal-tgiannakopoulos avatar Sep 19 '24 15:09 pal-tgiannakopoulos