Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

React Native 0.36 and 0.37 Support #582

Closed
richardhuaaa opened this issue Oct 25, 2016 · 18 comments
Closed

React Native 0.36 and 0.37 Support #582

richardhuaaa opened this issue Oct 25, 2016 · 18 comments

Comments

@richardhuaaa
Copy link
Contributor

richardhuaaa commented Oct 25, 2016

  • react-native-code-push version: 1.15.0-beta
  • react-native version: 0.36.0/0.37.0

RN 0.36.0 has not been officially tested against CodePush yet, but we will verify this within the next two days. If you have tested this and run into specific issues, please post them here! In the meantime, RN 0.35 has been verified against CodePush.

@brettpappas
Copy link

everything is working for me using 0.36 and 1.15.0-beta

@ericnograles
Copy link

Working nicely using 0.36 and 1.15.0-beta for me as well!

@vonovak
Copy link
Contributor

vonovak commented Oct 31, 2016

btw rn-diff repo might help figuring out whether something got broken

@richardhuaaa
Copy link
Contributor Author

I was able to verify that everything is working smoothly on RN 0.36, with the exception of specifically immediate restarts, on Android specifically. Most of our users are not using this method to install their updates, but if anybody is urgently in need of this, please upvote/comment and I will prioritize accordingly!

@jerson
Copy link

jerson commented Nov 2, 2016

immediate restarts on Android :(

@tomauty
Copy link

tomauty commented Nov 3, 2016

Yes please. What's the recommended 'next best thing' to immediate restarts for mandatory updates?

@EladPlayground
Copy link

I can confirm that IMMEDIATE and ON_NEXT_RESUME mandatory installation crashes. Any suggestions?

@richardhuaaa
Copy link
Contributor Author

Basically, something has changed in React Native that has caused the mechanism we use to restart/re-construct the app to crash (hence why it only affects IMMEDIATE/ON_NEXT_RESUME). I am investigating it now, but if anyone has any pointers that would also be really appreciated! This is the stack trace, it seems like the old instance of the app is not cleanly destroyed.

W/unknown:React: Tried to enqueue runnable on already finished thread: 'native_modules... dropping Runnable.
W/MessageQueue: Handler (com.facebook.react.bridge.queue.MessageQueueThreadHandler) {ca8f682} sending message to a Handler on a dead thread
                java.lang.IllegalStateException: Handler (com.facebook.react.bridge.queue.MessageQueueThreadHandler) {ca8f682} sending message to a Handler on a dead thread
                    at android.os.MessageQueue.enqueueMessage(MessageQueue.java:543)
                    at android.os.Handler.enqueueMessage(Handler.java:643)
                    at android.os.Handler.sendMessageAtTime(Handler.java:612)
                    at android.os.Handler.sendMessageDelayed(Handler.java:582)
                    at android.os.Handler.post(Handler.java:338)
                    at com.facebook.react.bridge.queue.MessageQueueThreadImpl.runOnQueue(MessageQueueThreadImpl.java:61)
                    at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
                    at android.os.Handler.handleCallback(Handler.java:751)
                    at android.os.Handler.dispatchMessage(Handler.java:95)
                    at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:31)
                    at android.os.Looper.loop(Looper.java:154)
                    at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:196)
                    at java.lang.Thread.run(Thread.java:761)
W/unknown:React: Tried to enqueue runnable on already finished thread: 'native_modules... dropping Runnable.
W/MessageQueue: Handler (com.facebook.react.bridge.queue.MessageQueueThreadHandler) {ca8f682} sending message to a Handler on a dead thread
                java.lang.IllegalStateException: Handler (com.facebook.react.bridge.queue.MessageQueueThreadHandler) {ca8f682} sending message to a Handler on a dead thread
                    at android.os.MessageQueue.enqueueMessage(MessageQueue.java:543)
                    at android.os.Handler.enqueueMessage(Handler.java:643)
                    at android.os.Handler.sendMessageAtTime(Handler.java:612)
                    at android.os.Handler.sendMessageDelayed(Handler.java:582)
                    at android.os.Handler.post(Handler.java:338)
                    at com.facebook.react.bridge.queue.MessageQueueThreadImpl.runOnQueue(MessageQueueThreadImpl.java:61)
                    at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
                    at android.os.Handler.handleCallback(Handler.java:751)
                    at android.os.Handler.dispatchMessage(Handler.java:95)
                    at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:31)
                    at android.os.Looper.loop(Looper.java:154)
                    at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:196)
                    at java.lang.Thread.run(Thread.java:761)

@richardhuaaa richardhuaaa changed the title React Native 0.36 Support React Native 0.36 and 0.37 Support Nov 8, 2016
@richardhuaaa
Copy link
Contributor Author

It seems like the onHostResume() event on React's LifeCycleEventListener has been modified to fire immediately when added if the app is in the foreground, rather than waiting for it to be backgrounded and then resumed. This has caused a few downstream effects which I'm still investigating.

@benedicthsieh
Copy link

So I believe that as a result of this bug, any deployment that has a mandatory upgrade anywhere in its history will now crash starting from a clean install, is that correct? That's what we're seeing with our deployment. I'm guessing it's because even after we pushed a non-mandatory upgrade to 'hide' the mandatory one, the upgrade itself will still happen with mandatory behavior (due to the behavior specced under 'Mandatory Parameter' here: https://microsoft.github.io/code-push/docs/cli.html#link-10.

Can we fix our codepush production deployment by clearing history code-push deployment clear? The docs say not to do this in a production environment, but I'm not sure what else we could do.

@richardhuaaa
Copy link
Contributor Author

richardhuaaa commented Nov 14, 2016

Hi @benedicthsieh - my sincere apologies, we will release a compatible update for RN 0.36 and 0.37 today or tomorrow. In the mean-time, I think the best way would be to patch the offending release using the code-push patch command.

@benedicthsieh
Copy link

Patching the mandatory flag out of our history worked, thanks for the tip!

@richardhuaaa
Copy link
Contributor Author

richardhuaaa commented Nov 16, 2016

I was able to fix the crash and rollback (originally caused by our resume handler being triggered twice due to a change in RN's LifeCycleEventManager).

Separately, I was not able to prevent the following warning being logged to the console on immediate/resume-based restarts when run in debug mode. It is coming from somewhere in React Native, but I'm unable to pinpoint exactly which object is attempting to queue the Runnable, as the behavior changes when breakpoints are set.

However, this warning seems to be completely benign - it will be logged to the console anywhere from 0-2 times on restart, and appears to depend on the order in which React Native objects are re-initialized. Other than that, there are no ill effects.

W/unknown:React: Tried to enqueue runnable on already finished thread: 'native_modules... dropping Runnable.
W/MessageQueue: Handler (com.facebook.react.bridge.queue.MessageQueueThreadHandler) {ca8f682} sending message to a Handler on a dead thread
                java.lang.IllegalStateException: Handler (com.facebook.react.bridge.queue.MessageQueueThreadHandler) {ca8f682} sending message to a Handler on a dead thread
                    at android.os.MessageQueue.enqueueMessage(MessageQueue.java:543)
                    at android.os.Handler.enqueueMessage(Handler.java:643)
                    at android.os.Handler.sendMessageAtTime(Handler.java:612)
                    at android.os.Handler.sendMessageDelayed(Handler.java:582)
                    at android.os.Handler.post(Handler.java:338)
                    at com.facebook.react.bridge.queue.MessageQueueThreadImpl.runOnQueue(MessageQueueThreadImpl.java:61)
                    at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
                    at android.os.Handler.handleCallback(Handler.java:751)
                    at android.os.Handler.dispatchMessage(Handler.java:95)
                    at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:31)
                    at android.os.Looper.loop(Looper.java:154)
                    at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:196)
                    at java.lang.Thread.run(Thread.java:761)

@richardhuaaa
Copy link
Contributor Author

I have released the fix to react-native-code-push@1.16.0-beta (release notes). Please feel free to use RN 36 and 37!

In future we will endeavor to ensure compatibility earlier in the cycle, including verifying React Native 0.38.0 before it comes out next week.

Please let us know if you have any feedback!

@richardhuaaa
Copy link
Contributor Author

@jerson, @codyhazelwood, @tomauty, @ivpusic, @EladPlayground, @benedicthsieh

@burgalon
Copy link

burgalon commented Jan 25, 2017

@Silhouettes I'm experiencing this exception when calling codePush.appRestart() manually, with RN 0.39.2 and react-native-code-push 1.17.0-beta

W/unknown:React( 1483): Tried to enqueue runnable on already finished thread: 'native_modules... dropping Runnable.
W/MessageQueue( 1483): Handler (com.facebook.react.bridge.queue.MessageQueueThreadHandler) {536e9bbc} sending message to a Handler on a dead thread
W/MessageQueue( 1483): java.lang.RuntimeException: Handler (com.facebook.react.bridge.queue.MessageQueueThreadHandler) {536e9bbc} sending message to a Handler on a dead thread
W/MessageQueue( 1483): 	at android.os.MessageQueue.enqueueMessage(MessageQueue.java:294)
W/MessageQueue( 1483): 	at android.os.Handler.sendMessageAtTime(Handler.java:473)
W/MessageQueue( 1483): 	at android.os.Handler.sendMessageDelayed(Handler.java:446)
W/MessageQueue( 1483): 	at android.os.Handler.post(Handler.java:263)
W/MessageQueue( 1483): 	at com.facebook.react.bridge.queue.MessageQueueThreadImpl.runOnQueue(MessageQueueThreadImpl.java:61)
W/MessageQueue( 1483): 	at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
W/MessageQueue( 1483): 	at android.os.Handler.handleCallback(Handler.java:615)
W/MessageQueue( 1483): 	at android.os.Handler.dispatchMessage(Handler.java:92)
W/MessageQueue( 1483): 	at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:31)
W/MessageQueue( 1483): 	at android.os.Looper.loop(Looper.java:137)
W/MessageQueue( 1483): 	at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:196)
W/MessageQueue( 1483): 	at java.lang.Thread.run(Thread.java:856)

@richardhuaaa
Copy link
Contributor Author

HI @burgalon, that is a warning rather than an exception, and it seems to be benign. Basically, when the app restarts, there may be some messages left in the queue targeting the old React Native instance. These messages will be dropped, but that's okay because that's what we want (we're rebooting the app from scratch).

@beansoft
Copy link

beansoft commented Mar 8, 2017

I've found an problem which causes this exception, eg my React JS used a customized native component, however this native component doesn't added to the ReactInstanceManager.Builder by method addPackage, then this problem will occur.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants