Fix app lagging while attempting a connection to Metro#48642
Closed
EdmondChuiHW wants to merge 1 commit into
Closed
Fix app lagging while attempting a connection to Metro#48642EdmondChuiHW wants to merge 1 commit into
EdmondChuiHW wants to merge 1 commit into
Conversation
facebook-github-bot
added
CLA Signed
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D68023397 |
EdmondChuiHW
force-pushed
the
export-D68023397
branch
from
99f7ae1 to
6995730
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D68023397 |
EdmondChuiHW
force-pushed
the
export-D68023397
branch
from
6995730 to
0e184ca
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D68023397 |
EdmondChuiHW
force-pushed
the
export-D68023397
branch
from
0e184ca to
7dec62b
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D68023397 |
EdmondChuiHW
force-pushed
the
export-D68023397
branch
from
7dec62b to
53f796d
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D68023397 |
Summary: Changelog: [General][Breaking][Fixed] - removed a long-running loop causing the app to lag while attempting a connection to Metro D65952134 fixed the auto-reconnection between Metro and the device. There's an existing "constructed = connected" contract as [discussed](https://www.internalfb.com/diff/D65952134?dst_version_fbid=3741052436109227&transaction_fbid=581445277659906): https://www.internalfb.com/code/fbsource/[1592525fbcbb]/xplat/js/react-native-github/packages/react-native/ReactCommon/jsinspector-modern/WebSocketInterfaces.h?lines=16-20 In compliance, busy-waiting was [introduced](https://www.internalfb.com/diff/D65952134?dst_version_fbid=896147259315683&transaction_fbid=427393513742494) in V4 to wait for the connection result in the constructor. xArthasx [discovered](https://www.internalfb.com/diff/D65952134?dst_version_fbid=896147259315683&transaction_fbid=1406890420289706) a performance issue from this impl via a profiling result. In favour of async connection results, we're going back to V3 design with the imperative `isConnected()` check to the interface. xArthasx has confirmed this fixes the perf issue. While I haven't found a compelling reason against removing this contract from the initial design in D52134592, please let me know if I've missed one. This also means there was a scenario where messages were sent before the websocket is open. Those were dropped silently previously (before the busy-waiting while loop was introduced): https://www.internalfb.com/code/fbsource/[f7113e167ee1]/fbobjc/VendorLib/SocketRocket/src/SocketRocket/SRWebSocket.m?lines=630-637 This means message senders must now consider the connection state, e.g. by maintaining a pre-connection message queue, if they need to guarantee the messages to be sent. Reviewed By: christophpurrer Differential Revision: D68023397
EdmondChuiHW
force-pushed
the
export-D68023397
branch
from
53f796d to
c42e833
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D68023397 |
Contributor
|
This pull request has been merged in 0e5adb9. |
Collaborator
|
This pull request was successfully merged by @EdmondChuiHW in 0e5adb9 When will my fix make it into a release? | How to file a pick request? |
ghost
pushed a commit
to discord/react-native
that referenced
this pull request
Jul 29, 2025
Summary: Pull Request resolved: facebook#48642 Changelog: [General][Breaking][Fixed] - removed a long-running loop causing the app to lag while attempting a connection to Metro D65952134 fixed the auto-reconnection between Metro and the device. There's an existing "constructed = connected" contract as [discussed](https://www.internalfb.com/diff/D65952134?dst_version_fbid=3741052436109227&transaction_fbid=581445277659906): https://www.internalfb.com/code/fbsource/[1592525fbcbb]/xplat/js/react-native-github/packages/react-native/ReactCommon/jsinspector-modern/WebSocketInterfaces.h?lines=16-20 In compliance, busy-waiting was [introduced](https://www.internalfb.com/diff/D65952134?dst_version_fbid=896147259315683&transaction_fbid=427393513742494) in V4 to wait for the connection result in the constructor. xArthasx [discovered](https://www.internalfb.com/diff/D65952134?dst_version_fbid=896147259315683&transaction_fbid=1406890420289706) a performance issue from this impl via a profiling result. In favour of async connection results, we're going back to V3 design with the imperative `isConnected()` check to the interface. xArthasx has confirmed this fixes the perf issue. While I haven't found a compelling reason against removing this contract from the initial design in D52134592, please let me know if I've missed one. This also means there was a scenario where messages were sent before the websocket is open. Those were dropped silently previously (before the busy-waiting while loop was introduced): https://www.internalfb.com/code/fbsource/[f7113e167ee1]/fbobjc/VendorLib/SocketRocket/src/SocketRocket/SRWebSocket.m?lines=630-637 This means message senders must now consider the connection state, e.g. by maintaining a pre-connection message queue, if they need to guarantee the messages to be sent. Reviewed By: christophpurrer Differential Revision: D68023397 fbshipit-source-id: dd80acf75790e77454798c96f06bb0a4ee6afe61
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
Changelog:
[General][Breaking][Fixed] - removed a long-running loop causing the app to lag while attempting a connection to Metro
D65952134 fixed the auto-reconnection between Metro and the device.
There's an existing "constructed = connected" contract as discussed:
https://www.internalfb.com/code/fbsource/[1592525fbcbb]/xplat/js/react-native-github/packages/react-native/ReactCommon/jsinspector-modern/WebSocketInterfaces.h?lines=16-20
In compliance, busy-waiting was introduced in V4 to wait for the connection result in the constructor.
xArthasx discovered a performance issue from this impl via a profiling result.
In favour of async connection results, we're going back to V3 design with the imperative
isConnected()check to the interface. xArthasx has confirmed this fixes the perf issue.While I haven't found a compelling reason against removing this contract from the initial design in D52134592, please let me know if I've missed one.
This also means there was a scenario where messages were sent before the websocket is open. Those were dropped silently previously (before the busy-waiting while loop was introduced):
https://www.internalfb.com/code/fbsource/[f7113e167ee1]/fbobjc/VendorLib/SocketRocket/src/SocketRocket/SRWebSocket.m?lines=630-637
This means message senders must now consider the connection state, e.g. by maintaining a pre-connection message queue, if they need to guarantee the messages to be sent.
Differential Revision: D68023397