Avoid crash by handling missing views in dispatchViewManagerCommand

[hsource]

Summary

Based on Google Play crash logs, crashes due to the assertions in dispatchViewManagerCommand is our top source of crashes:

com.facebook.react.uimanager.IllegalViewOperationException: Unable to execute operation dispatchViewManagerCommand: blur on view with tag: 17549, since the view does not exists
        at com.facebook.react.uimanager.UIImplementation.assertViewExists(UIImplementation.java:830)
        at com.facebook.react.uimanager.UIImplementation.dispatchViewManagerCommand(UIImplementation.java:713)
        at com.facebook.react.uimanager.UIManagerModule.dispatchCommand(UIManagerModule.java:739)
        at com.facebook.react.uimanager.UIManagerModule.dispatchViewManagerCommand(UIManagerModule.java:726)
        at com.facebook.react.uimanager.ReanimatedUIManager.dispatchViewManagerCommand(ReanimatedUIManager.java:233)
        at java.lang.reflect.Method.invoke(Method.java:-2)
        at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
        at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:151)
        at com.facebook.react.bridge.queue.NativeRunnable.run(NativeRunnable.java:-2)

There are many other places in UIImplementation that instead of throwing a fatal exception, just log a message and continues execution.

Logging a message and discarding the command should be safe for commands like "blur this view". We keep the previous behavior in debug mode, but just log and discard commands in production.

Changelog

[Android] [Fixed] - Avoid crash by handling missing views in dispatchViewManagerCommand

Test Plan

We had a tough time reproducing specific crashes, but we ran with this binary in the latest release of our app and it has eliminated this class of crashes from Google Play and Bugsnag instrumentation.

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	7,792,708	-137
android	hermes	armeabi-v7a	7,196,078	-144
android	hermes	x86	8,103,397	-140
android	hermes	x86_64	8,082,731	-145
android	jsc	arm64-v8a	9,665,413	-10
android	jsc	armeabi-v7a	8,437,549	-15
android	jsc	x86	9,616,715	-11
android	jsc	x86_64	10,213,230	-7

Base commit: 7c581f3
Branch: main

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
ios	-	universal	n/a	--

Base commit: 7c581f3
Branch: main

[JoshuaGross]

We do something similar for Fabric, so I'm supportive of backporting this change.

In the case of Fabric, we have special exceptions that are thrown and soft-logged instead of ignoring the error entirely: https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/MountItemDispatcher.java#L222-L231

In practice these warnings haven't provided much value and it's pretty normal for there to be races between ViewCommands and Views being unmounted, so I think just ignoring them is fine.

[facebook-github-bot]

@JoshuaGross has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[JoshuaGross]

I would even support logging a soft-exception or just logging an error to logcat (but not crashing) in debug mode, I don't think that crashing in these cases is helpful, even in debug. But I won't block merging this either way.

[JoshuaGross]

Additionally, in Fabric we actually have logic to retry ViewCommands exactly once (maybe the command was executed too quickly, before the View was created? Maybe it's being executed after the View was deleted? We don't really know, so we try again in the next UI frame). It's worth considering that here too, but again, I won't block this PR as it's an improvement over the status quo for non-Fabric.

[react-native-bot]

This pull request was successfully merged by @hsource in ee1a191.

^{When will my fix make it into a release? | Upcoming Releases}