[v0.74] Android: Promises from native modules stuck

[birdofpreyru]

Description

Hey, I am upgrading an existing app from RN v0.73.6 to v0.74.1, trying to make it work for Android, new architecture, bridge-less (and the app was working fine on RN v0.73 with new arch, and bridge; I haven't tested bridge-less before).

I've encountered an issue that shortly after running the app promises from native modules stuck to resolve or reject. I.e. in my code I have some function, say doSmth(): Promise<void> (which is a TS-side definition for a native function in a native module) that is called repeatedly, does some work on the native side, then does promise.resolve(null) on the native side, to resolve the pending promise on the TS side. It works for me fine at first, but after some call the promise from doSmth() just stuck indefinitely without either resolve or reject.

I've added console logging both at native and TS side, so I see that promise.resolve(null) is called at native side for that pending promise (i.e. I see console log from the line just before it); the call to promise.resolve(null) does not fail (I have the native block of code wrapped into try/catch, and a log statement in catch does not print); but on the TS side that promise stays pending (again, if I haven't miss anything, on TS side I have console statements just before the promise, after awaiting it, and I have entire block wrapped into try/catch with another console statement; and it nor statement after awaiting, nor in the catch prints).

So... I am still trying to further dig into it, but already creating the ticket, just in case somebody has seen something similar, or has some helpful ideas / insights.

P.S.: In my current understanding, smth happens in C++ code implementation of promise resolution; and as of now I have no idea how to debug that in an RN app :grimacing: Ideally, I guess, I want to stick debugger breakpoint here in C++ code, to see what happens, but how? If in Android Studio I set breakpoints into C++ code of RN they do not seem to have effect :(

And I have confirmed that my app works seemingly fine with v0.74.1 if I disable bridge-less mode.

Steps to reproduce

N/A

React Native Version

N/A

Affected Platforms

Runtime - Android

Areas

Other (please specify)

Output of npx react-native info

N/A

Stacktrace or Logs

N/A

Reproducer

N/A

Screenshots and Videos

No response

[github-actions[bot]]

:warning:	Add or Reformat Version Info
:information_source:	We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.70.2

[github-actions[bot]]

:warning:	Missing Reproducible Example
:information_source:	We could not detect a reproducible example in your issue report. Please provide either: If your bug is UI related: a Snack If your bug is build/update related: use our Reproducer Template. A reproducer needs to be in a GitHub repository under your username.

[birdofpreyru]

Hey @cortinico , any thoughts about this one? I am not sure what can I do — I can't get Android Studio debugger to work on C++ RN code; I don't see any apparent issues with my code on TS & Java side; and although the issue reliably happens shortly after the app start-up, it is not in an deterministic way, sometimes I get it sooner, sometimes later.

It feels like perhaps some dependency in the app, not correctly migrated to the new arch, does something wrong with communications to the native layer, and somehow rapidly exhaust the ability of bridgleless communication to handle new callbacks / promises... but I don't see anything in adb logcat logs, or app behavior hinting on where to look for the problem (though my first guess would be react-native-webview, or @react-native-firebase to blame — both poorly maintained, and using some weird patterns in their code, which I haven't seen in RN docs).

[cortinico]

Hey @cortinico , any thoughts about this one?

I'd say, let's start by attaching a reproducer to this issue. This week we're all busy with ReactConf so we won't be able to take a look at it

[birdofpreyru]

This week we're all busy with ReactConf

I hope, ReactConf was fun :)

Regarding my issue — following the trial-and-error approach, I tried to comment out different parts of my app relying on different 3rd party libraries, and narrowed it down to react-native-google-mobile-ads — if I don't use any functionality from it, my app works fine. Though, while I was testing that library got some fixes... thus, I am still to try whether the problem is there with v13.3.1 of that library, and if so, what might be causing it.

[birdofpreyru]

@cortinico I have narrowed it down to the issue still happening with react-native-google-mobile-ads v13.3.0, and the issue not present after it upgrade to v13.3.1 and above. The only code change between these versions seems to be a change in event name: https://github.com/invertase/react-native-google-mobile-ads/compare/v13.3.0...v13.3.1

I am not sure why that event name was changed, and how may it affect unrelated promises not being resolved in the bridgeless mode. Though, if it makes any sense, I'd say RN misses to detect some problem here, and warn about it, or probably throw a hard error.

[RSNara]

@birdofpreyru, it's very tough for us to diagnose this issue without code examples, or a reproducer.

I strongly urge you to to create a minimal reproducer! I think that'll be the quickest way to see this problem resolved.

[chrisnojima]

Hi, I don't have a minimal reproducer but I do want to chime in that I believe I also have this issue on ios. When bridgeless is on my promises that cross the bridge do not resolve, but with bridgeless off they do resolve