[RN 0.70.0-rc.2] React Native Lottie - function getModule: assertion failed (moduleAsValue.isObject())

[AlexanderEggers]

Description

While testing the latest RC version, I've noticed the following error when starting the application:

Abort message: '/Users/alex/Documents/Projects/lottie-react-native/fabric-example/node_modules/react-native/ReactCommon/react/renderer/uimanager/bindingUtils.cpp:29: function getModule: assertion failed (moduleAsValue.isObject())'

@cortinico - I have provided a more simplified example project in my current WIP branch.

Version

0.70.1

Output of npx react-native info

System: OS: macOS 12.5 CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz Memory: 125.38 MB / 16.00 GB Shell: 5.8.1 - /bin/zsh Binaries: Node: 16.14.2 - /usr/local/bin/node Yarn: 1.22.18 - ~/.yarn/bin/yarn npm: 5.1.0 - ~/Documents/Projects/lottie-react-native/node_modules/.bin/npm Watchman: Not Found Managers: CocoaPods: 1.11.3 - /Users/alex/.rbenv/shims/pod SDKs: iOS SDK: Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5 Android SDK: API Levels: 28, 29, 30, 31, 32, 33 Build Tools: 30.0.2, 30.0.3, 31.0.0 System Images: android-29 | Google Play Intel x86 Atom, android-31 | Google Play Intel x86 Atom_64, android-32 | Google APIs Intel x86 Atom_64, android-32 | Google Play Intel x86 Atom_64, android-33 | Google APIs Intel x86 Atom_64, android-33 | Google Play Intel x86 Atom_64 Android NDK: Not Found IDEs: Android Studio: 2021.2 AI-212.5712.43.2112.8815526 Xcode: 13.4.1/13F100 - /usr/bin/xcodebuild Languages: Java: 11.0.16 - /usr/bin/javac npmPackages: @react-native-community/cli: Not Found react: 18.1.0 => 18.1.0 react-native: 0.70.0-rc.2 => 0.70.0-rc.2 react-native-macos: Not Found npmGlobalPackages: react-native: Not Found

Steps to reproduce

1. Clone https://github.com/AlexanderEggers/lottie-react-native/tree/feature/add-fabric-support
2. yarn install
3. cd lib
4. yarn build
5. cd ../examples/fabric
6. yarn android

Snack, code example, screenshot, or link to a repository

https://github.com/AlexanderEggers/lottie-react-native/tree/feature/add-fabric-support

[cortinico]

Thanks for reporting. For reference this a duplicate of #34056 #33618 As you provided a repro, we can investigate further 👍 I'll get back to you

[cortinico]

I'll get back to you

I've done further testing and it seems like the AppRegistry issue is actually related to a variety of different JS errors that make the JS runtime crash.

You mentioned you had a branch working with New Architecture right? Could link it to me?

[AlexanderEggers]

I'll get back to you

I've done further testing and it seems like the AppRegistry issue is actually related to a variety of different JS errors that make the JS runtime crash.

You mentioned you had a branch working with New Architecture right? Could link it to me?

Yeah I had a local branch with that. I will try to provide you with something by early next week. I will let you know.

[JesseLawler]

Any follow-up on this? I'm getting essentially the same issue (but with RN 0.69.4) and am wondering if there's a way forward or if I need to roll back to the old architecture.

[Orange9000]

In my case the reason for the getModule: assertion failed crash was this line: NativeModules.I18nManager.localeIdentifier, which I used to determine device language in one of my app's startup screens. By removing that I was at least able to go past certain startup operations like redux rehydration etc, but my app still crashes after that.

So in general, I may assume the mentioned above type of errors has something to do with calling native functions from js.

I was able to determine the cause for the crash by using logs from Flipper's Device -> Logs section. Hope that helps someone.

[AlexanderEggers]

I had a look into providing a RN69 example but I had to fully recreate that case because I removed the relevant branch already. Unfortunately that new branch is crashing now with the same error mentioned above. The underlying crash is definitely related to something this library integration is doing or generated based on the new arch specs. When removing the package from the example project, I can run the application without issues.

[natioskar]

Hello, I'm getting the same kind of error after upgrading from 0.67.x, happens to me on 0.69, 0.70.rc3-4, and 0.70 stable that recently went out.

E0905 22:27:22.525616 54329344 bindingUtils.cpp:27] getModule of AppRegistry is not an object E0905 22:27:22.525718 54329344 bindingUtils.cpp:29] react_native_assert failure: moduleAsValue.isObject() Assertion failed: (moduleAsValue.isObject()), function getModule, file bindingUtils.cpp, line 29.

I saw in a couple of other threads that the issue is not reproducing on a clean bootstrapped project, unfortunately in my case moving to a new skeleton project is not an option, many configurations and different environments are configured making it not a possible solution.

Anyone was able to pinpoint what exactly cause the issue? I've tried comparing all sorts of files in my project with the example project with no success so far

[fawad-khalil]

@AlexanderEggers I am facing the same problem. RN version is 0.70.1 and I have installed iOS pods using new architecture and Fabric. Is there any update related to this issue?

[cortinico]

I'm getting essentially the same issue (but with RN 0.69.4) and am wondering if there's a way forward or if I need to roll back to the old architecture.

Please refrain from commenting 'same issue' without providing further context. At this stage, we need a simple reproducer with a single component that crash with the aformentioned error message and we can look into it.

[AlexanderEggers]

@cortinico I updated the project to the latest stable 0.70.x version and I also moved the project structure to yarn berry workspaces - unfortunately I still have the same problem. The linked branch contains all the latest changes. I would be grateful if you could have another look and help me understand where that potential assertion failure could be located.

Steps to reproduce:

1. Clone https://github.com/AlexanderEggers/lottie-react-native/tree/feature/add-fabric-support
2. yarn install
3. yarn setup
4. yarn fabric:android

[cortinico]

@AlexanderEggers Thanks for doing so. I'll look through it.

I experienced the same issues in the past (@cipolleschi as well). The native crash is most likely triggered by a wrong import on the JS side of things.

[cipolleschi]

It could also be that you are calling a method in JS which is not implemented in Native.

[AlexanderEggers]

@cipolleschi I had another look and did a few more changes to introduce typescript for the fabric spec to the project but no change to the issue.

I noticed that the actual component is created correctly but as soon as the component communicates with the native layer (via the generated Commands), the crash happens. So yes it would indicate there is somewhere a mismatch but according to the provided generated classes from the CLI there should be no issues. 🤔

In case you want to play around with the latest branch changes:

1. Clone https://github.com/AlexanderEggers/lottie-react-native/tree/feature/add-fabric-support
2. yarn install
3. yarn setup
4. yarn fabric:android

cc @cortinico

[alfonsocj]

I tried removing codegenNativeCommands and all props from NativeProps just to see if it rendered and I can see that it errors out with Invariant Violation: View config getter callback for component LottieAnimationView must be a function (received undefined), which means that it's not even recognizing the native module.

[alfonsocj]

I think this issue has to do with how metro is configured on a monorepo/yarn workspaces like this one. I tried linking packages/core to a RN 0.70.3 app that's not part of the repo and I don't see those issues.

[AlexanderEggers]

@alfonsocj Thank you so much for looking into this problem from a different angle.

Based on your observations, I found the issue which was indeed part of the metro config file. I replaced my config with https://github.com/th3rdwave/react-native-safe-area-context/blob/main/fabric-example/metro.config.js for my fabric example project and seems to be working fine now. I believe that this specific behaviour really needs to be well documented for the new arch - these specific metro config changes were never needed for the old arch.

I also got the react-native-lottie library finally compatible with android for fabric 🎉 Just ios is missing but hopefully that won't take as much time. 🤞

[cortinico]

I also got the react-native-lottie library finally compatible with android for fabric 🎉 Just ios is missing but hopefully that won't take as much time. 🤞

Wow that's awesome! Thanks for doing that. I had this issue in my inbox but I haven't found the time to look into it. Glad this got solved!

[douglowder]

I hit this assertion failure today in RNTester while working on the move to 0.70.3 for the Apple TV/Android TV fork.

I decided to debug it by just commenting out the react_native_assert() call and then see what happened... sure enough I then saw a Metro message that probably points to the real issue 👍

 ERROR  Invariant Violation: TurboModuleRegistry.getEnforcing(...): 'Vibration' could not be found. Verify that a module by this name is registered in the native binary.

[douglowder]

@cortinico I thought about this some more -- should we consider removing this assertion for debug builds, to allow the real issue to surface in Metro?

[only1chi]

@douglowder I have the same problem and I tried commenting out the react_native_assert() call, but nothing happened. I do know that the app is crashing because the AppRegistry seems to be returning an empty object.

I wonder if anyone has any other suggestions or tips?

[cortinico]

I have the same problem and I tried commenting out the react_native_assert() call, but nothing happened.

Yup @douglowder as @only1chi, removing the Assert is not sufficient. The failure is happening earlier in the execution time and we're not raising it early enough. The AppRegistry being null is just a symptom of the underlying failure.

[only1chi]

@cortinico Any idea how I can expose the error since it's happening so early? At the moment, it feels more like guess work.

[cortinico]

At the moment, it feels more like guess work.

Yeah I know the pain. We don't have a solution for this specific instance at this stage, sadly. We're looking into it and hopefully come with a solution in the near future.

Any PR is also welcome in this space 🙏

[antskelton]

The native crash is most likely triggered by a wrong import on the JS side of things.

@cortinico's comment is as accurate as it is understated!

I've spent many hours bisecting this issue, and found it to be caused by any uncaught exception raised by code that runs before the call to AppRegistry.registerComponent().

In my case, I was importing my package.json (several levels deep in the import chain from index.js) and then dereferencing a non-existent property.

After fixing up a lot of similar issues, app runs fine. It's only unfortunate that the assertion makes them quite laborious to find.

[only1chi]

@cortinico I did go through all the node-module packages and updated all the packages that were still using the deprecated ViewPropTypes. However, I'm running into another issue with gesture handler best described here.

The gist of it is that when react-native-gesture-handler is being built, it does not locate the react-native-codegen library, and it attempts to build from the script folder. Any thoughts on how to solve this?

[cortinico]

it does not locate the react-native-codegen

Have you tried looking into the codegenDir property of the react{} block in the build.gradle file that lets you customize where codegen is located?

[j-piasecki]

Have you tried looking into the codegenDir property of the react{} block in the build.gradle file that lets you customize where codegen is located?

@cortinico It may not be as simple as that, as applying the com.facebook.react plugin in the library's build.gradle seems to be overriding the paths set in the react{} block with the default ones.

[cortinico]

@cortinico It may not be as simple as that, as applying the com.facebook.react plugin in the library's build.gradle seems to be overriding the paths set in the react{} block with the default ones.

@j-piasecki could you elaborate on this? It's the first time we're hearing about this kind of behavior

[j-piasecki]

@cortinico when you set the codegenDir property in the react{} block in the app's build.gradle it doesn't propagate to the third-party libraries. What I believe is happening is when a library applies com.facebook.react plugin in its build.gradle the plugin is using the default values for all the properties, even if some are set in the app project.

Using something like

project.pluginManager.withPlugin("com.facebook.react") {
    react {
        reactNativeDir = rootProject.file("../../../node_modules/react-native/")
        codegenDir = rootProject.file("../../../node_modules/react-native-codegen/")
    }
}

allows to work around this, but requires all modules be on the same level so the paths are correct.