java.lang.NullPointerException: key must not be null com.revenuecat.purchases.common.caching.DeviceCache.cleanupOldAttributionData(DeviceCache.kt:165)

[AntonioCappiello]

java.lang.NullPointerException: key must not be null
com.revenuecat.purchases.common.caching.DeviceCache.cleanupOldAttributionData(DeviceCache.kt:165)
com.revenuecat.purchases.identity.IdentityManager.configure(IdentityManager.kt:41)
com.revenuecat.purchases.Purchases.(Purchases.kt:160)
com.revenuecat.purchases.Purchases.(Purchases.kt:94)
com.revenuecat.purchases.PurchasesFactory.createPurchases(PurchasesFactory.kt:88)
com.revenuecat.purchases.Purchases$Companion.configure(Purchases.kt:2065)
com.revenuecat.purchases.Purchases.configure(Purchases.kt:2)

A simple null check should fix this issue, i.e.:

@Synchronized
fun cleanupOldAttributionData() {
    val editor = preferences.edit()
    for (key in preferences.all.keys) {
        if (key != null && key.startsWith(attributionCacheKey)) {
            editor.remove(key)
        }
    }
    editor.apply()
}

Can you please add this to the next release?
I have paying users who cannot open the app anymore because the app crash on startup due to this issue.

[RCGitBot]

👀 SDKONCALL-205 We've just linked this issue to our internal tracker and notified the team. Thank you for reporting, we're checking this out!

[codykerns]

Hey @AntonioCappiello! Just providing an update here from what we talked about in the support ticket - the SDK team is investigating the underlying cause of the issue and will provide an update soon.

[aboedo]

Hey @AntonioCappiello following up here:

We have a fix (#742) in place, we're going to merge and ship it very soon.

Sorry we took a bit, but we wanted to audit to try to understand why this could happen in the first place, to ensure that just doing the check wouldn't mean that we have a bug we're just living with and that patching might mean something else breaks down the road.

We couldn't really find any way to reproduce this solely within the SDK, but we did find that if SharedPreferences has a value stored with null as the key, this bug would reproduce.

Any chance this is what was happening in your case?

[AntonioCappiello]

Thanks for the update. By setting a key to null was the only way I had to reproduce it. By the time we last spoke, I have already rolled out in prod a fix which would cleanup null keys before calling the RC sdk. That worked. I don’t explicitly set null as key anywhere in my app. My thought was that somebody might have try to temper the app or that some device manufacturer do some weird stuff with the shared pref. Your fix will do, but I think an even better way would be if you had your own shared preference file instead of using the app's default one. This way, you will have more guarantee that developers might mess up with any of the values you set. I have seen in other libraries do that…I mean having their own preference file. Again, thanks for the fix and have a nice day! Cheers, Antonio

…

On 17 Jan 2023, at 13:15, Andy Boedo ***@***.***> wrote: Hey @AntonioCappiello <https://github.com/AntonioCappiello> following up here: We have a fix (#742 <#742>) in place, we're going to merge and ship it very soon. Sorry we took a bit, but we wanted to audit to try to understand why this could happen in the first place, to ensure that just doing the check wouldn't mean that we have a bug we're just living with and that patching might mean something else breaks down the road. We couldn't really find any way to reproduce this solely within the SDK, but we did find that if SharedPreferences has a value stored with null as the key, this bug would reproduce. Any chance this is what was happening in your case? — Reply to this email directly, view it on GitHub <#737 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJVWA46CU3S7MLXHDAFO63WS2EOPANCNFSM6AAAAAATZBDDJQ>. You are receiving this because you were mentioned.

[aboedo]

@AntonioCappiello that is valid feedback, thanks! We're going to look into it

[github-actions]

This issue has been automatically locked due to no recent activity after it was closed. Please open a new issue for related reports.