👋 @mkevins, gave this solution a go and seems to work OK. Thing is, I am not sure what's the full set of assumptions ReactInstanceManager.onHostDestroy() assumes, and it seems that we need to dive into the implementation to understand what's going on.

@hypest I wanted to attempt to address your question from #1288 (comment), since I was able to dig into this issue this week and resolve some side effects (pending review) that we were seeing from @mkevins fix for wordpress-mobile/WordPress-Android#10227.

In particular, the question to answer would be: does the onHostDestroy() lead to destroying the React context that holds the app and the data? If yes, under which circumstances?

So ReactInstanceManager.onHostDestroy() definitely does not destroy ReactContext that holds app data. You can see that ReactInstanceManager was created with a clear distinction between its destroy method which specifically "Destroy[s] this react instance and the attached JS context" and it's onHostDestroy method which calls onHostDestroy methods of our ReactContext's ActivityEventListeners, and then sets our Activity reference to null (code link).

Those same ActivityEventListeners instances will have their onHostResume functions called from our WPAndroidGlueCode onResume function:

In short, ReactInstanceManager seems to make assumptions that Activity references can be updated via its onHostDestroy, onHostResume lifecycle, while preserving its ReactContext. Since the activity reference passed into our ReactInstanceManager.onHostDestroy() is in fact destroyed, and the main responsibility of onHostDestroy is to clean up ActivityEventListeners which may rely on that destroyed Activity, I think this change should be relatively harmless, (and beneficial!).

👍 @cameronvoell , thanks for having a deep look.

Thanks Cameron for summarizing the lifecycle methods behavior, and for finding a solution to the side effects exposed by the draft fix. Very nice work on part 2 👍 .

The simplest way I found to do this was to emit a message to our React Native Bridge that we are closing any open modals.

This makes sense to me, and works well. I've tested via the steps in the description, and everything is now working as expected.

I think proposing the change to Open Source library would be complicated because the way we utilize our React Native instance inside a "headless" fragment is non standard, so this use case may not apply to most people.

I agree on this point too. Since our app architecture requires us to "color outside the lines" a bit, I'm unsure how readily our proposed changes would be accepted upstream.