NullPointerException at DefaultEventProcessor

[orafaaraujo]

Hello

Describe the bug We are facing a crash in the library.

To reproduce We're unable to reproduce it, but according to our logs on Firebase, it happens once the app goes to the background.

Expected behavior No crash at all

Logs The stack trace

Fatal Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.Object.hashCode()' on a null object reference
       at libcore.reflect.TypeVariableImpl.hashCode(TypeVariableImpl.java:47)
       at java.util.HashMap.hash(HashMap.java:338)
       at java.util.HashMap.get(HashMap.java:556)
       at com.google.gson.internal.$Gson$Types.resolve($Gson$Types.java:353)
       at com.google.gson.internal.$Gson$Types.resolve($Gson$Types.java:396)
       at com.google.gson.internal.$Gson$Types.resolve($Gson$Types.java:343)
       at com.google.gson.internal.$Gson$Types.getSupertype($Gson$Types.java:288)
       at com.google.gson.internal.$Gson$Types.getCollectionElementType($Gson$Types.java:307)
       at com.google.gson.internal.bind.CollectionTypeAdapterFactory.create(CollectionTypeAdapterFactory.java:52)
       at com.google.gson.Gson.getAdapter(Gson.java:489)
       at com.google.gson.Gson.toJson(Gson.java:727)
       at com.google.gson.Gson.toJson(Gson.java:714)
       at com.google.gson.Gson.toJson(Gson.java:669)
       at com.google.gson.Gson.toJson(Gson.java:649)
       at com.launchdarkly.sdk.android.DefaultEventProcessor$Consumer.postEvents(DefaultEventProcessor.java:145)
       at com.launchdarkly.sdk.android.DefaultEventProcessor$Consumer.flush(DefaultEventProcessor.java:139)
       at com.launchdarkly.sdk.android.DefaultEventProcessor$Consumer.run(DefaultEventProcessor.java:122)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
       at java.lang.Thread.run(Thread.java:1012)

SDK version 3.1.5

Language version, developer tools Kotlin 1.6, AGP 7.3.1, Android 33

OS/platform Android 12 (API 33)

Additional context

[louis-launchdarkly]

Hello @orafaaraujo, thank you for the report on this issue. While this event loop call should not cause any real issues for your application (the event loop is on a separate thread that doesn't impact getting and using flag values), this is still something that we need to look into.

While there is no exact ETA yet, we also have a new major version in the pipeline that will improve Android in general, we will reply on this either when we have new information or when the new version comes out.

Filed Internally as 175693.

[audkar]

While this event loop call should not cause any real issues for your application (the event loop is on a separate thread

Android system sets default global uncaught exception handler to kill whole process. It doesn't matter that Exception is thrown on separate thread.

that doesn't impact getting and using flag values

This impacts not just getting/using flags, but whole production application is terminated. That's what being reported in stack-trace: Fatal Exception. Whole process goes kaput :skull_and_crossbones:

[louis-launchdarkly]

@audkar Thank you for the information.

@orafaaraujo We have released 4.0.0 which fully replaced the DefaultEventProcessor that was in android with an improved one. If it is possible for you to upgrade, can you upgrade and let us know if this issue is still happening? For the upgrade path, please refer to https://github.com/launchdarkly/android-client-sdk/blob/main/CHANGELOG.md#400---2022-12-07

[DmytroBatyuk]

try to use

     LDContext.builder("unknown")
            .anonymous(true)
            .build()

while initializing a client. LDContext should have not empty key

[louis-launchdarkly]

Thank you @DmytroBatyuk for the answer - we are currently looking into potentially revamping the key generation behavior as Android requiring the placeholder key is something that can be missed and some other LaunchDarkly SDKs don't do that.

[tanderson-ld]

We are closing this issue due to a combination of inactivity, code changes that likely alter the relevant region of code, and the SDK version this issue was reported against reaching end-of-life.