-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Comments
everything is working for me using 0.36 and 1.15.0-beta |
Working nicely using 0.36 and 1.15.0-beta for me as well! |
btw rn-diff repo might help figuring out whether something got broken |
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! |
immediate restarts on Android :( |
Yes please. What's the recommended 'next best thing' to immediate restarts for mandatory updates? |
I can confirm that IMMEDIATE and ON_NEXT_RESUME mandatory installation crashes. Any suggestions? |
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
|
It seems like the |
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 |
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 |
Patching the mandatory flag out of our history worked, thanks for the tip! |
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 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 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.
|
I have released the fix to 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! |
@Silhouettes I'm experiencing this exception when calling 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) |
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). |
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. |
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.
The text was updated successfully, but these errors were encountered: