React-native-onesignal: Android app crashes with: 'Fatal Exception: java.lang.RuntimeException: Illegal callback invocation from native module. This callback type only permits a single invocation from native code."

[cristygrant]

Description:
We are using this library to send push notifications to a react native app running on android and iPhone devices. During app startup, we do a request to onesignal to get available tags for the device.
OneSignal.getTags((receivedTags) => { //do something });
This works well in iPhone devices, however on Android devices, the app crashes during startup with the following error:

Fatal Exception: java.lang.RuntimeException: Illegal callback invocation from native module. This callback type only permits a single invocation from native code.
at com.facebook.react.bridge.CallbackImpl.invoke(CallbackImpl.java:28)
at com.geektime.rnonesignalandroid.RNOneSignal$1.tagsAvailable(RNOneSignal.java:100)
at com.onesignal.OneSignal$14.run(OneSignal.java:1489)
at java.lang.Thread.run(Thread.java:818)

Environment
App is using "react-native-onesignal": "^3.1.4" installed through npm
-->

[Nightsd01]

Hi @cristygrant , thanks for posting this issue.

Are you able to easily reproduce this issue? Does it happen 100% of the time, or only sometimes?

This error indicates that the getTags() callback is being called more than once by the Android SDK, which should not be happening.

Does it only occur for a single user, or everyone who uses your app?

[gabceb]

Thanks for the prompt reply @Nightsd01. I work with @cristygrant. See below our Fabric.io crashalytics charts with some numbers on the crashes. We had the saga that runs the sync tags request on startup for around 48 hours during the weekend which means low traffic for our app.

Our iOS fabric is showing crashes as well but I am working on fixing some dSYM issues. Will post once we have iOS data

[gabceb]

Here is a session's full stacktrace for all running threads stacktrace.txt

[cristygrant]

We fixed the dSYM issues for iOS and confirmed there were no crashes related to this for iOS. Seems to be an issue for Android only.

[Nightsd01]

Hi @cristygrant @cristygrant @gabceb

We recently introduced an update to the SDK (3.2.1) that includes some Android synchronization fixes. Can you tell me if you still encounter this issue in 3.2.1?

[gabceb]

We will do a partial release tomorrow or Monday and will let you know since we have not been able to reproduce it locally. Greatly appreciated it @Nightsd01

[gabceb]

@Nightsd01 we are now stuck on https://github.com/geektimecoil/react-native-onesignal/issues/491#issuecomment-388934066. We will move to the new way of doing things and let you know when we release the new version

[cristygrant]

@Nightsd01 we have done a partial release with SDK 3.2.1 and already have a number of users that have experienced this issue.

[Nightsd01]

Hi @cristygrant

3.2.0 was a relatively large update and had some issues - we've released 3.2.3 to fix a major iOS initialization issue.

However since you are still encountering this issue, we'll continue to investigate.

The Android native SDK should not be calling the same callback twice in the first place. We'll investigate to see why this is happening.

In the mean time, we'll release a react-native SDK update shortly (either tomorrow or within the next few days) that will check to ensure it doesn't happen.

[cristygrant]

@Nightsd01 does the newly released 3.2.4 react-native SDK update contain the fix you mention above?

[cristygrant]

Hi @Nightsd01. Any updates on the release that will check to ensure same callback is not being called twice? Thanks in advance!

[cristygrant]

👋@Nightsd01 any updates on this?

[Nightsd01]

Hi @cristygrant, we were able to reproduce this issue and were able to fix it (#548). It will be in the next release, should be out some time early next week! Thanks for your patience, sorry for the delay

[Nightsd01]

Also, this crash would only occur if your app calls getTags() multiple times, _very_ rapidly. While our SDK should not crash because of this, it’s still unnecessary, so I would suggest refactoring your app to make sure it doesn’t call getTags() so often

[cristygrant]

@Nightsd01 thank you so much for the update! We're eager to test the fix once it is released.

[Nightsd01]

Issue has been resolved in 3.2.5! Thanks for your patience

[SvetoslavSlavov]

@Nightsd01 After the update my app crash from the start. I can't open it. My React Native version is 0.55.3. I upgrade using yarn with this command yarn upgrade react-native-onesignal@^3.2.5

[rahamin1]

Update 13/10:

It seems that the tested version has some build issues. After building again, we don't see more crashes with version 3.2.6.

Original post:

This crash happens to me on Android 6 and Android 7.1, using RN-oneSignal version 3.2.5.
getTags is being called in componentDidMount of a component that is mounted only when a user selects it from the UI. I don't see how it can be called very often. There is only one user.

Answers to @Nightsd01 questions from above:

Are you able to easily reproduce this issue? Does it happen 100% of the time, or only sometimes?

Only sometimes, it is hard to reproduce it.

This error indicates that the getTags() callback is being called more than once by the Android SDK, which should not be happening.

As I wrote above, I don't see how it can be called very often from our app. Strange.

Does it only occur for a single user, or everyone who uses your app?

tested on multiple devices.

[magick93]

Can we please have this issue reopened.

[scottmas]

This issue should be reopened. It is still happening on 3.2.7.

Right now I have a workaround where I use promise-queue to ensure that only one getTags() is called at a time, but occasionally it still crashes, annoyingly.

[scottmas]

Note that the error is slightly different:

The callback getTags() exists in module OneSignal, but only one callback may be registered to a function in a native module.

[ahartzog]

Sentry stack trace for this issue, in case it's helpful. Still seeing a .005% crash rate on this. Not massive, but annoying.