🔥Crash on Android on v1.1.1: Tried to access a JS module before the React instance was fully set up

[taschik]

🐛 Bug Report

Our Android users are experiencing crashes across different Android versions (Android 7-10) and devices with the following stack trace:

Fatal Exception: java.lang.RuntimeException: Tried to access a JS module before the React instance was fully set up. Calls to ReactContext#getJSModule should only happen once initialize() has been called on your native module.
       at com.facebook.react.bridge.ReactContext.getJSModule(ReactContext.java:118)
       at com.facebook.reactnative.androidsdk.FBAccessTokenModule$1.onCurrentAccessTokenChanged(FBAccessTokenModule.java:51)
       at com.facebook.AccessTokenTracker$CurrentAccessTokenBroadcastReceiver.onReceive(AccessTokenTracker.java:110)
       at androidx.localbroadcastmanager.content.LocalBroadcastManager.executePendingBroadcasts(LocalBroadcastManager.java:313)
       at androidx.localbroadcastmanager.content.LocalBroadcastManager$1.handleMessage(LocalBroadcastManager.java:121)
       at android.os.Handler.dispatchMessage(Handler.java:112)
       at android.os.Looper.loop(Looper.java:216)
       at android.app.ActivityThread.main(ActivityThread.java:7625)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:524)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:987)

About 8% of all our Android users are affected but only roughly half of them use Facebook login. 6% of the device state is in background.

To Reproduce

Following the Crashlytics logs of affected users, it seems to happen during the initialization. Often a session_start event followed by max one screen_view event is all we see before the app crashing.

Expected Behavior

The app should not crash.

Environment

"react-native-fbsdk": "^1.1.1",

System:
    OS: macOS 10.15.1
    CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
    Memory: 97.33 MB / 32.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 10.16.3 - /usr/local/bin/node
    Yarn: 1.17.3 - /usr/local/bin/yarn
    npm: 6.9.0 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  SDKs:
    iOS SDK:
      Platforms: iOS 13.2, DriverKit 19.0, macOS 10.15, tvOS 13.2, watchOS 6.1
    Android SDK:
      API Levels: 23, 26, 27, 28
      Build Tools: 23.0.1, 25.0.0, 26.0.3, 27.0.3, 28.0.1, 28.0.2, 28.0.3
      System Images: android-24 | Google APIs Intel x86 Atom, android-24 | Google Play Intel x86 Atom, android-27 | Google APIs Intel x86 Atom, android-28 | Google APIs Intel x86 Atom, android-29 | Google APIs Intel x86 Atom
  IDEs:
    Android Studio: 3.5 AI-191.8026.42.35.5791312
    Xcode: 11.2.1/11B500 - /usr/bin/xcodebuild
  npmPackages:
    react: ^16.8.6 => 16.9.0
    react-native: ^0.60.5 => 0.60.5
  npmGlobalPackages:
    eslint-plugin-react-native: 3.5.0
    react-native-cli: 2.0.1
    react-native-git-upgrade: 0.2.7

[taschik]

It seems I am not the only one as I just discovered this bug fix PR: #674
Could the maintainer team perhaps take a look at it and merge?

[chgsilva]

i am having the same bug

[chgsilva]

any updates on this issue?

[joelfsreis]

same problem here is there any update?

[chgsilva]

I am using an old version of the lib while waiting for the fix

[joelfsreis]

@chgsilva can you please share which version you are using? Thanks

[ahanriat]

@joelfsreis 1.0.4 is working fine

[taschik]

I can confirm, downgrading to 1.0.4 helps but certainly not a long term solution.

[mikehardy]

Happening to me as well - anyone use 1.1.1 with the linked PR integrated? I'll try but curious for other success reports

[chgsilva]

any updates on this?

[mikehardy]

@chgsilva The linked PR #674 is working for me in production via patch-package