Xcode 10 runtime warning on fresh install: nw_socket_handle_socket_event

mog3n commented 6 years ago

Description

While running the boilerplate react native app, I receive the runtime error: 2018-09-09 21:46:07.681496-0400 client[2035:560210] [] nw_socket_handle_socket_event [C6.2:1] Socket SO_ERROR [61: Connection refused] 2018-09-09 21:46:07.681861-0400 client[2035:560216] [] nw_connection_get_connected_socket [C6] Client called nw_connection_get_connected_socket on unconnected nw_connection 2018-09-09 21:46:07.681903-0400 client[2035:560216] TCP Conn 0x2821ac300 Failed : error 0:61 [61] which loops over and over for the duration of debugging the app on a device. I'm not sure exactly what this error is associated with, however in my other app I receive the same error. This may or may not be related to remote push notifications (APNs).

Environment

React Native Environment Info: System: OS: macOS 10.14 CPU: x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz Memory: 27.59 MB / 16.00 GB Shell: 3.2.57 - /bin/bash Binaries: Node: 9.8.0 - /usr/local/bin/node Yarn: 1.5.1 - /usr/local/bin/yarn npm: 5.6.0 - /usr/local/bin/npm Watchman: 4.9.0 - /usr/local/bin/watchman SDKs: iOS SDK: Platforms: iOS 11.4, macOS 10.13, tvOS 11.4, watchOS 4.3 IDEs: Xcode: 9.4.1/9F2000 - /usr/bin/xcodebuild npmPackages: react: 16.4.1 => 16.4.1 react-native: 0.56.0 => 0.56.0 npmGlobalPackages: create-react-native-app: 1.0.0 react-native-cli: 2.0.1

Reproducible Demo

react-native init
react-native run-ios
In Capabilities, enable both 'Notifications' and Background Modes -> Enable 'Remote notifications'
Open Xcode and select a connected iPhone
Launch/debug the app and open the Xcode console

A couple of notes:

Device is iPhone X on iOS 12.0 beta (16A5366a)
Building the app using Xcode 10.0 beta 2 (10L177m) beta, while react-native run-ios builds using Xcode 9.4.1
macOS is running 10.14 Beta (18A377a)

aleclarson commented 5 years ago

If you're using react-native-macos, this solution will help you:

https://medium.com/@mimicatcodes/how-to-get-rid-of-unwanted-logs-in-the-console-xcode-8-6c1909ed75d8

Side note: NSLog calls won't be visible, so be sure to use RCTLog instead. (when using Objective-C)

mmmulani commented 5 years ago

@aleclarson thanks for the workaround.

Again, "+1" or "me too" comments are not helpful.

rudyryk commented 5 years ago

I'm using XCode for watching logs. This is very convinient. Faster and deeper in any case than debugging via browser based remote debugger or via react dev tools. Why react native team totally ignores this issue is extremely strange to me and even make me think of switching to another platform.

Yes, I prefer to use native platform tools. For MacOS and iOS development this is XCode. We don't need more than that. OK, we also must use some editor for JavaScript and auto-started NodeJS based packager. But please, don't force extras, that's already too much!

a8851625 commented 5 years ago

so no ones cares about this isssue!?it has been a long time for opened here!!it's very affecting the progress of work

xiao99xiao commented 5 years ago

Upgraded to 0.58.5 and the issue still exists.

For those who don't understand why this is so annoying: Our app use Cocoapods to integrate React Native and is developed by React Native developers and native developers at the same time. As seen from native developers, we don't install React Dev Tools so the app could never get connected to a dev tool, which leads the infinite trolling of the nw_socket_handle_socket_event log every second, making the Xcode console totally unusable.

For those who have been annoyed like me: Since facebook never wants to solve this issue, I figured out a way to make it stop. The credit goes to @anilmanukonda . If you are like me using Cocoapods to integrate React, and don't use React Dev Tools, add the code below to your podfile, then in Xcode Clean Build Folder, rebuild.

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      if target.name == 'React' and config.name == 'Debug' then
        config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] = ['$(inherited)', 'RCTLOG_ENABLED=0', 'ENABLE_PACKAGER_CONNECTION=0', 'RCT_ENABLE_INSPECTOR=0']
      end
    end
  end
end

noahtallen commented 5 years ago

@xiao99xiao it seems the bot closed it because someone merged a PR yesterday that's supposed to fix it. Do you think that'll resolve your particular situation?

xiao99xiao commented 5 years ago

@noahtallen Thanks for clarifying. Seems it should resolve the issue in my case, however I can't verify it until next React Native release and my React Native developer collegue updates our project. I should leave the question to others here :)

sunnylqm commented 5 years ago

Seems we still need to wait for https://github.com/facebook/react-devtools/pull/1248 to fix this issue

msand commented 5 years ago

@sunnylqm I made a build of my patch (cherry picked it on top of v3.4.2 first, which is the version used/locked in the 0.58-stable branch of react-native) and published it to github: https://github.com/msand/react-devtools-core You can try it using e.g. yarn add react-devtools-core@msand/react-devtools-core#4c30959

msand commented 5 years ago

Also cherry picked the patch on top of the 3.6.0 release (which is the one used in 0.59-stable), in case you want the latest version and hooks support etc. yarn add react-devtools-core@msand/react-devtools-core#4880490

msand commented 5 years ago

At least the 0.59-stable branch contains my patch for react-native, and is available starting from 0.59.0-rc.3 which was released three days ago.

msand commented 5 years ago

So, if you run:

react-native init --version 0.59.0-rc.3 MyNewApp
cd MyNewApp
yarn add react-devtools-core@msand/react-devtools-core#4880490
react-native run-ios

Then you should be free from errors.

msand commented 5 years ago

Actually the patch seems to be available in the 0.58-stable branch as well, starting with 0.58.6 which was released two days ago. So, running:

react-native-git-upgrade

or

yarn add react-native

(and adjusting the react version etc.)

And then:

yarn add react-devtools-core@msand/react-devtools-core#4c30959
react-native run-ios

Should work as well. The same applies for react-native init without specifying a version (until 0.59 is released).

asafgunay commented 5 years ago

Actually the patch seems to be available in the 0.58-stable branch as well, starting with 0.58.6 which was released two days ago. So, running:
react-native-git-upgrade
or
yarn add react-native
(and adjusting the react version etc.)

And then:
yarn add react-devtools-core@msand/react-devtools-core#4c30959
react-native run-ios
Should work as well. The same applies for react-native init without specifying a version (until 0.59 is released).

Thanks it solved issue!

yarn add react-native
yarn add react-devtools-core@msand/react-devtools-core#4c30959

dembe1 commented 5 years ago

@msand First of all, thanks for taking care of this!

I am also having this issue, however I still have not managed to solve it. My Xcode logs are piling up with nw_socket_handle_socket_event [C581.2:1] Socket SO_ERROR [61: Connection refused] entries, the number of Xcode's ports in the activity monitor increase by ~20 per second, as described above. In addition to that, any XHR requests I make from my app seem to display a failure with a huge delay (like 1-2 minutes), is it possible that they are blocked/queued?

It is important to mention that all of this only happens when testing with a real device (iPhone XS, iOS 12.1.4). With a simulated iPhone XS, iOS 12.1, I don't get any of these errors.

I upgraded to RN 0.58.6 via react-native-git-upgrade as described in the React Native documentation successfully and executed npm install react-devtools-core@msand/react-devtools-core#4c30959 --save (instead of yarn add react-devtools-core@msand/react-devtools-core#4c30959, hope that was correct).

Am I missing something?

This is quite frustrating, since it not only clogs the log view, but also seems to block my XHR requests. But since I am new to RN, maybe it's me! :) Thanks in advance.

AkioUnity commented 5 years ago

Still, I have same issues with latest version

sunnylqm commented 5 years ago

Try yarn upgrade react-native(if your rn version already >=0.58.6) to upgrade react-devltools-core to the latest version 3.6.1, which includes the patch.

msand commented 5 years ago

If you're still having issues, can you make a reproducible demo? Preferably with a fresh empty project with nothing else: react-native init MyNewApp

dembe1 commented 5 years ago

If you're still having issues, can you make a reproducible demo? Preferably with a fresh empty project with nothing else: react-native init MyNewApp

Unfortunately, I still can't get it to work, even with a freshly set up project. I created a repo with the code and a readme, including a screenshot - if there is any other info that can help figuring out the issue, please let me know. Thanks!

https://github.com/dembe1/rn-connection-issue

msand commented 5 years ago

Ah, you're using a real device no? I guess you have some firewall issues or need to open some ports. I don't have access to any iPhone so I can't really help you with that.

msand commented 5 years ago

Have you done this? https://facebook.github.io/react-native/docs/running-on-device#2-ip-address

cjroth commented 5 years ago

So, if you run:

react-native init --version 0.59.0-rc.3 MyNewApp
cd MyNewApp
yarn add react-devtools-core@msand/react-devtools-core#4880490
react-native run-ios

Then you should be free from errors.

Thanks for working on this @msand!

I just inited a clean 0.59.0-rc.3 app and this is still happening for me :\

iPhone X (Device, not simulator)
iOS 12.1.4

zfanta commented 5 years ago

Thanks @msand, does react-native version matter? I upgraded react-devtools-core to 3.6.1 in my project that uses react-native v0.58.1. But the issue does not solved.

demo here: https://github.com/zfanta/demo

sunnylqm commented 5 years ago

@zfanta Yes, rn version must be >= 0.58.6

joelgetaction commented 5 years ago

Have you done this? https://facebook.github.io/react-native/docs/running-on-device#2-ip-address

Hey @msand , I tried this and it doesn't help. I'm still seeing my Xcode logs spammed by this socket message. I'm on RN 0.58.6.

joelgetaction commented 5 years ago

Hi @msand, I tried adding yarn add react-devtools-core@msand/react-devtools-core#4c30959 to my 0.58.6 RN project and then stopped metro and did a clean build and run in Xcode but that didn't help. I am still seeing Xcode's log spammed with the following every 2 seconds:

019-03-08 16:07:53.483125-0800 BidVidClientMobile[40953:7799138] TCP Conn 0x280fcc300 Failed : error 0:61 [61]
2019-03-08 16:07:55.496783-0800 BidVidClientMobile[40953:7799138] [] nw_socket_handle_socket_event [C33.1:1] Socket SO_ERROR [61: Connection refused]
2019-03-08 16:07:55.499286-0800 BidVidClientMobile[40953:7799138] [] nw_socket_handle_socket_event [C33.2:1] Socket SO_ERROR [61: Connection refused]
2019-03-08 16:07:55.500128-0800 BidVidClientMobile[40953:7799132] [] nw_connection_get_connected_socket [C33] Client called nw_connection_get_connected_socket on unconnected nw_connection

Also the number of open ports in Xcode as visible in Activity Monitor is going up and up without limit. I am running on an actual iPhone on iOS 12.

Any ideas? It appears that the patch does NOT fix the issue and this is really making it difficult to do any Xcode logging (and the ports may be exhausted at some point) ...

Or did I need to do something else after installing the devltools patch?

Thanks for all of your help with this!

msand commented 5 years ago

I haven't had any iPhone since I started doing react-native things. So I've never had a real iPhone connected to Xcode yet, and can't really help you with that. Do you have the debugger and inspector working? Otherwise, perhaps someone else who has that working in this thread can help you. I would suspect the debugger doesn't work either in case you're still getting errors.

dembe1 commented 5 years ago

After a couple of hours of debugging, breakpoint hunting and diving into the React Native Libraries, I have found a solution that at least works for me.

TL; DR

Add the following line in your AppDelegate.m (you have to put it right below the line starting with jsCodeLocation = [[RCTBundleURLProvider sharedSettings] ...):

[[RCTBundleURLProvider sharedSettings] setJsLocation:jsCodeLocation.host];

The long version

The problem is a reconnecting WebSocket trying to access the Metro packager via http://localhost:8081/message?role=ios, which cannot be resolved, because localhostfrom the device's point of view would be itself, whereas the packager is still running on your MacBook. This is also the reason why this issue only occurs on actual devices and not when running the simulator on a MacBook. Therefore, the iPhone needs to access the package manager through your MacBook's URL in the local network.

The problem is located in line 63 of the init function of React Native's RCTPackagerConnection class. It reads the value of the RCTBundleURLProvider's jsLocation property, which is never being set, hence it is empty. Now I don't know whether we are all missing some configuration part that would lead this to be set properly, but for me this is always empty. In the end, line 84 of RCTPackagerConnection falls back to localhostif no jsLocation was set.

Interestingly enough, there is a fancy mechanism to set the URL accordingly, implemented in RCTBundleURLProvider) and react-native/scripts/react-native-xcode.sh. The shell script is automatically executed as part of the Xcode build steps of every RN project. This mechanism will write your MacBook's IP address to a text file called ip.txt and allow RN on the device to read from it afterwards. By the way, the script also used to use xip.io as a workaround to the problem that the ATS (App Transport Security) doesn't allow non-HTTPS URLs, however xip.io has been removed from the code entirely a year ago. Unfortunately, React Native's official documentation has not been updated accordingly, adding to the frustration when trying to fix these kind of issues.

Now the weird part is that the mechanism to determine the IP address and passing it to the app on the device is only applied in the context of the first bootstrapping scripts in AppDelegate.m (inside the jsBundleURLForBundleRoot call):

jsCodeLocation = [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil];

RCTRootView *rootView = [[RCTRootView alloc] initWithBundleURL:jsCodeLocation
                                             moduleName:@"CookingBuddyMobileApp"
                                             initialProperties:nil
                                             launchOptions:launchOptions];

The WebSockets trying to (re-)connect to the packager afterwards don't know the IP and, as described above, fall back to localhost. Therefore, setting the RCTBundleURLProvider's jsLocation property in AppDelegate.m fixes the issue:

jsCodeLocation = [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil];

[[RCTBundleURLProvider sharedSettings] setJsLocation:jsCodeLocation.host]; 

RCTRootView *rootView = [[RCTRootView alloc] initWithBundleURL:jsCodeLocation
                                             moduleName:@"CookingBuddyMobileApp"
                                             initialProperties:nil
                                             launchOptions:launchOptions];

This basically re-uses the existing jsCodeLocation property (which takes advantage of the fancy ip.txt mechanism mentioned above) and simply extracts the host (i.e. the IP address) from it (since jsCodeLocation is a full URL with scheme, path etc.) and sets the RCTBundleURLProvider's jsLocationproperty accordingly. This leads to all WebSockets to initialize correctly (i.e. not with localhostURLs, but with your MacBook's IP address.

I hope this helps! And if someone has a more "elegant solution", I would love to hear it.

@msand To me it seems as if this is a bug in RN, but I am not sure. Do you think it would be worth opening a new issue, or re-opening this one?

msand commented 5 years ago

@dembe1 Excellent work! It probably makes sense to open a new issue, and make a new pull request referencing that. It'll probably get more attention from the maintainers that way as this issue is already closed. Can of course reference this issue from the new one, that'll give good context for any maintainers to evaluate the nature of the bug and fix.

vadermemo commented 5 years ago

After a couple of hours of debugging, breakpoint hunting and diving into the React Native Libraries, I have found a solution that at least works for me.

TL; DR

Add the following line in your AppDelegate.m (you have to put it right below the line starting with jsCodeLocation = [[RCTBundleURLProvider sharedSettings] ...):
[[RCTBundleURLProvider sharedSettings] setJsLocation:jsCodeLocation.host];
The long version

The problem is a reconnecting WebSocket trying to access the Metro packager via http://localhost:8081/message?role=ios, which cannot be resolved, because localhostfrom the device's point of view would be itself, whereas the packager is still running on your MacBook. This is also the reason why this issue only occurs on actual devices and not when running the simulator on a MacBook. Therefore, the iPhone needs to access the package manager through your MacBook's URL in the local network.

The problem is located in line 63 of the init function of React Native's RCTPackagerConnection class. It reads the value of the RCTBundleURLProvider's jsLocation property, which is never being set, hence it is empty. Now I don't know whether we are all missing some configuration part that would lead this to be set properly, but for me this is always empty. In the end, line 84 of RCTPackagerConnection falls back to localhostif no jsLocation was set.

Interestingly enough, there is a fancy mechanism to set the URL accordingly, implemented in RCTBundleURLProvider) and react-native/scripts/react-native-xcode.sh. The shell script is automatically executed as part of the Xcode build steps of every RN project. This mechanism will write your MacBook's IP address to a text file called ip.txt and allow RN on the device to read from it afterwards. By the way, the script also used to use xip.io as a workaround to the problem that the ATS (App Transport Security) doesn't allow non-HTTPS URLs, however xip.io has been removed from the code entirely a year ago. Unfortunately, React Native's official documentation has not been updated accordingly, adding to the frustration when trying to fix these kind of issues.

Now the weird part is that the mechanism to determine the IP address and passing it to the app on the device is only applied in the context of the first bootstrapping scripts in AppDelegate.m (inside the jsBundleURLForBundleRoot call):
jsCodeLocation = [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil];

RCTRootView *rootView = [[RCTRootView alloc] initWithBundleURL:jsCodeLocation
                                             moduleName:@"CookingBuddyMobileApp"
                                             initialProperties:nil
                                             launchOptions:launchOptions];
The WebSockets trying to (re-)connect to the packager afterwards don't know the IP and, as described above, fall back to localhost. Therefore, setting the RCTBundleURLProvider's jsLocation property in AppDelegate.m fixes the issue:
jsCodeLocation = [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil];

[[RCTBundleURLProvider sharedSettings] setJsLocation:jsCodeLocation.host]; 

RCTRootView *rootView = [[RCTRootView alloc] initWithBundleURL:jsCodeLocation
                                             moduleName:@"CookingBuddyMobileApp"
                                             initialProperties:nil
                                             launchOptions:launchOptions];
This basically re-uses the existing jsCodeLocation property (which takes advantage of the fancy ip.txt mechanism mentioned above) and simply extracts the host (i.e. the IP address) from it (since jsCodeLocation is a full URL with scheme, path etc.) and sets the RCTBundleURLProvider's jsLocationproperty accordingly. This leads to all WebSockets to initialize correctly (i.e. not with localhostURLs, but with your MacBook's IP address.

I hope this helps! And if someone has a more "elegant solution", I would love to hear it.

@msand To me it seems as if this is a bug in RN, but I am not sure. Do you think it would be worth opening a new issue, or re-opening this one?

Don't work on my project, same issue again

[3927:38003] [] nw_socket_handle_socket_event [C17.1:1] Socket SO_ERROR [61: Connection refused] a lot of times!

rajeshde commented 5 years ago

After a couple of hours of debugging, breakpoint hunting and diving into the React Native Libraries, I have found a solution that at least works for me.

TL; DR

Add the following line in your AppDelegate.m (you have to put it right below the line starting with jsCodeLocation = [[RCTBundleURLProvider sharedSettings] ...):
[[RCTBundleURLProvider sharedSettings] setJsLocation:jsCodeLocation.host];
The long version

The problem is a reconnecting WebSocket trying to access the Metro packager via http://localhost:8081/message?role=ios, which cannot be resolved, because localhostfrom the device's point of view would be itself, whereas the packager is still running on your MacBook. This is also the reason why this issue only occurs on actual devices and not when running the simulator on a MacBook. Therefore, the iPhone needs to access the package manager through your MacBook's URL in the local network.

The problem is located in line 63 of the init function of React Native's RCTPackagerConnection class. It reads the value of the RCTBundleURLProvider's jsLocation property, which is never being set, hence it is empty. Now I don't know whether we are all missing some configuration part that would lead this to be set properly, but for me this is always empty. In the end, line 84 of RCTPackagerConnection falls back to localhostif no jsLocation was set.

Interestingly enough, there is a fancy mechanism to set the URL accordingly, implemented in RCTBundleURLProvider) and react-native/scripts/react-native-xcode.sh. The shell script is automatically executed as part of the Xcode build steps of every RN project. This mechanism will write your MacBook's IP address to a text file called ip.txt and allow RN on the device to read from it afterwards. By the way, the script also used to use xip.io as a workaround to the problem that the ATS (App Transport Security) doesn't allow non-HTTPS URLs, however xip.io has been removed from the code entirely a year ago. Unfortunately, React Native's official documentation has not been updated accordingly, adding to the frustration when trying to fix these kind of issues.

Now the weird part is that the mechanism to determine the IP address and passing it to the app on the device is only applied in the context of the first bootstrapping scripts in AppDelegate.m (inside the jsBundleURLForBundleRoot call):
jsCodeLocation = [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil];

RCTRootView *rootView = [[RCTRootView alloc] initWithBundleURL:jsCodeLocation
                                             moduleName:@"CookingBuddyMobileApp"
                                             initialProperties:nil
                                             launchOptions:launchOptions];
The WebSockets trying to (re-)connect to the packager afterwards don't know the IP and, as described above, fall back to localhost. Therefore, setting the RCTBundleURLProvider's jsLocation property in AppDelegate.m fixes the issue:
jsCodeLocation = [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil];

[[RCTBundleURLProvider sharedSettings] setJsLocation:jsCodeLocation.host]; 

RCTRootView *rootView = [[RCTRootView alloc] initWithBundleURL:jsCodeLocation
                                             moduleName:@"CookingBuddyMobileApp"
                                             initialProperties:nil
                                             launchOptions:launchOptions];
This basically re-uses the existing jsCodeLocation property (which takes advantage of the fancy ip.txt mechanism mentioned above) and simply extracts the host (i.e. the IP address) from it (since jsCodeLocation is a full URL with scheme, path etc.) and sets the RCTBundleURLProvider's jsLocationproperty accordingly. This leads to all WebSockets to initialize correctly (i.e. not with localhostURLs, but with your MacBook's IP address.

I hope this helps! And if someone has a more "elegant solution", I would love to hear it.

@msand To me it seems as if this is a bug in RN, but I am not sure. Do you think it would be worth opening a new issue, or re-opening this one?

It worked for after I spent so many hours to find a fix. I am using...... react-native: 0.52.0 OSX: 10.14.3 Xcode: 10.1 iOS: 12.1.4

I haven't faced this issue in react-native version is 0.58.4 as the changes in react-native-xcode.sh mentioned in this solution, is already there.

joelgetaction commented 5 years ago

If you use an Expo bare app then you need to implement the solution of @deadwater88 in https://github.com/facebook/react-native/commit/7fce997ea5bd446b1410b347a02f21540c924d06 since the jsCodeLocation mentioned by @rajeshde is not in your AppDelegate.

LuisRizo commented 5 years ago

For me, @dembe1's solution didn't work since I'm using Electrode Native and we don't have that in our AppDelegate.m. However, we don't use sockets in our react-native app so I went to the source of the reconnections and prevented them from happening.

On RN 0.57.8 and electrode-native version 0.30, the culprit was RCTInspectorPackagerConnection.m at line 200.

- (void)webSocket:(RCTSRWebSocket *)webSocket didFailWithError:(NSError *)error
{
  if (_webSocket) {
    [self abort:@"Websocket exception"
      withCause:error];
  }
  if (!_closed) {
    [self closeAllConnections]; // <- Change to this. Before it was `[self reconnect];
  }
}

This removed all those annoying reconnect logs.

This change is a bit overkill, I'm sure commenting out the [self reconnect]; would have been enough, but since we don't use sockets, this is fine for us. It might have some side-effects, I'm no iOS expert, but it works for me, so maybe it will work for others.

UPDATE:

For my team members, that wasn't enough. I also had to remove the [self reconnect]; calls on RCTReconnectingWebSocket.m on lines 166 and 172.

After that, no more logs.

IAmMarcellus commented 5 years ago

I'm using react native 0.59.5 and I'm getting these errors. However this version of react native uses: RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge instead of RCTRootView *rootView = [[RCTRootView alloc] initWithBundleURL:jsCodeLocation so I can't implement the: [[RCTBundleURLProvider sharedSettings] setJsLocation:jsCodeLocation.host]; fix. Is there any way to implement that fix using the bridge instead of initWithBundle?

aibek-bird commented 5 years ago

Having the same issue on iOS 12.1.4, react-native: 0.59.5, XCode 10.2.1.

Runs many times:

2019-05-15 16:21:41.751022+0900 AppName[525:278667] TCP Conn 0x2820d4480 Failed : error 0:61 [61]
2019-05-15 16:21:43.869817+0900 AppName[525:252581] [] nw_socket_handle_socket_event [C25.1:1] Socket SO_ERROR [61: Connection refused]

Any updates?

kenjdavidson commented 5 years ago

Was having the same issue on:

IOS 12.2
XCode 12.2.1
RN 0.59.8

Looking at the comments on a number of posts I was able to resolve the issue by applying pretty much the same fix to AppDelegate.m. First of all, I'm terribly new to Objective-C so I'm sure this could be prettier, but its effective:

- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge
{
#if DEBUG
  NSURL *jsUrl = [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil];
  [[RCTBundleURLProvider sharedSettings] setJsLocation:jsUrl.host];
  return [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil];
#else
  return [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"];
#endif
}

thingthing commented 5 years ago

@kenjdavidson thanks, it works perfectly! Just you can optimize the code a little bit by reusing the jsUrl variable:

- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge
{
#if DEBUG
  NSURL *jsUrl = [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil];
  [[RCTBundleURLProvider sharedSettings] setJsLocation:jsUrl.host];
  return jsUrl;
#else
  return [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"];
#endif
}

GreenRidingHood commented 5 years ago

https://github.com/facebook/react-native/issues/24023#issuecomment-474608280 @patrickkempff 's solution possibly help

noahtallen commented 5 years ago

I'm also on 0.59.8 and the latest iOS and Xcode. My workaround looks like this:

- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge
{
#if DEBUG
  NSURL *jsUrl = [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil];
  [[RCTBundleURLProvider sharedSettings] setJsLocation:jsUrl.host];
  return jsUrl;
#else
  return [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"];
#endif
}

The errors are gone while I do have a JS debugger open, but

2019-05-26 13:10:24.616366-0400 zonder[73455:1923229] [] nw_socket_handle_socket_event [C224.1:1] Socket SO_ERROR [61: Connection refused]
2019-05-26 13:10:24.618005-0400 zonder[73455:1923229] [] nw_socket_handle_socket_event [C224.2:1] Socket SO_ERROR [61: Connection refused]
2019-05-26 13:10:24.618761-0400 zonder[73455:1923229] [] nw_connection_get_connected_socket [C224] Client called nw_connection_get_connected_socket on unconnected nw_connection

just repeats indefinitely while I'm not debugging JS. So I guess the solution isn't working for me :(

dan-abc commented 5 years ago

@noahtallen, @IAmMarcellus I’ve found moving the RCTBundleURLProvider call to applicationDidFinishLaunchingWithOptions seems to fix the nw_socket_handle_socket_event errors both in and not in JS debug mode.

[[RCTBundleURLProvider sharedSettings] setJsLocation:[self sourceURLForBridge:bridge].host];

I added the line directly after the [[RCTRootView alloc] initWithBridge:bridge... call.

noahtallen commented 5 years ago

@dshepherd Huh. I just tried that and the logs still show up for me

jvandenaardweg commented 5 years ago

Did all of the above, but did not really work. Then I noticed a CORS error in the Chrome debugger. Switched to React Native Debugger (https://github.com/jhen0409/react-native-debugger), rebuild the app, and it started working on my device.

The cors error prevented from connecting to the socket i guess

I hope this could be helpful to someone.

To summarize what I did:

Editted my AppDelegate.m to reflect the latest template version, as I was using a version that looked a bit different. Latest version: https://github.com/facebook/react-native/blob/master/template/ios/HelloWorld/AppDelegate.m
Then, editted my AppDelegate.m to use the change suggested above: https://github.com/facebook/react-native/issues/21030#issuecomment-493392051
Close any open Chrome debugger
Open the React Native Debugger
Clean build
Rebuild the App, target your own device
Wait for the Metro bundler to complete bundling (see your terminal), that could take a little. In the mean time you'll see websocket connection errors, as the bundler is not ready yet.
Wait for the app to open. Logs should now start flowing into React Native Debugger

While the app is running, you should not see any socket connection errors again in the logs

AppDelegate.m

```objective-c /** * Copyright (c) Facebook, Inc. and its affiliates. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. */ #import "AppDelegate.h" #import #import #import #import #import #import "RNSplashScreen.h" // iOS 9.x or newer // https://facebook.github.io/react-native/docs/linking #import @implementation AppDelegate // https://facebook.github.io/react-native/docs/linking - (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options { return [RCTLinkingManager application:application openURL:url options:options]; } - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { // Custom added [AppCenterReactNativeCrashes registerWithAutomaticProcessing]; [AppCenterReactNativeAnalytics registerWithInitiallyEnabled:false]; [AppCenterReactNative register]; RCTBridge *bridge = [[RCTBridge alloc] initWithDelegate:self launchOptions:launchOptions]; RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge moduleName:@"MyApp" initialProperties:nil]; // Custom editted // Original: // rootView.backgroundColor = [[UIColor alloc] initWithRed:1.0f green:1.0f blue:1.0f alpha:1]; rootView.backgroundColor = [UIColor blackColor]; self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds]; UIViewController *rootViewController = [UIViewController new]; rootViewController.view = rootView; self.window.rootViewController = rootViewController; [self.window makeKeyAndVisible]; // Custom added [RNSplashScreen show]; return YES; } - (NSURL *)sourceURLForBridge:(RCTBridge *)bridge { #if DEBUG // Custom added: // This prevents the logs from constantly showing websocket connection errors // https://github.com/facebook/react-native/issues/21030#issuecomment-493392051 // original: // return [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil]; NSURL *jsUrl = [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil]; [[RCTBundleURLProvider sharedSettings] setJsLocation:jsUrl.host]; return jsUrl; #else return [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"]; #endif } @end ```

noahtallen commented 5 years ago

I'm also using react native debugger (which works great like you say!), but the logs show up for me when I turn off remote JS debugging

jerodb commented 5 years ago

@dembe1 solution from Mar 10 worked for me. He gives an excellent explanation of this issue btw!

DataGreed commented 5 years ago

The same problem is still present even on 0.59.9, I wonder how facebook engineers don't run in the same issue on daily basis 🤔

DataGreed commented 5 years ago

Okay on 0.59.9 cleaning up the build folder and rebuilding the app helps. If you need a debuger, https://github.com/jhen0409/react-native-debugger works as @jvandenaardweg suggested (chrome debugger shows CORB errors).

The annoying thing is that even with the app working and debugger working I see a neverending stream of errors in xcode console:

2019-08-12 12:37:12.707914+0100 MyApp[13292:3989531] [] nw_socket_handle_socket_event [C15913.1:1] Socket SO_ERROR [61: Connection refused]
2019-08-12 12:37:12.708742+0100 MyApp[13292:3989531] [] nw_socket_handle_socket_event [C15913.2:1] Socket SO_ERROR [61: Connection refused]
2019-08-12 12:37:12.708899+0100 MyApp[13292:3989451] [] nw_connection_get_connected_socket [C15913] Client called nw_connection_get_connected_socket on unconnected nw_connection
2019-08-12 12:37:12.708912+0100 MyApp[13292:3989451] TCP Conn 0x28085ad00 Failed : error 0:61 [61]

I mean, what exactly is it trying to connect to? The Metro bundler works properly and the debugger is connected, what's happening?

msand commented 5 years ago

I think fb uses quite a different debug setup internally, and it's supposed to connect to that.

allnash commented 5 years ago

Kinda ridiculous, that everyone is struggling with the tools rather than the actual appplication code.

echokk11 commented 5 years ago

Xcode 11, IOS13, RN 0.57.8 stuck here.

2019-09-30 17:59:34.364815+0800 kardashian[8997:267918] [] nw_socket_handle_socket_event [C268.2:1] Socket SO_ERROR [61: Connection refused]
2019-09-30 17:59:34.365713+0800 kardashian[8997:267914] [] nw_connection_get_connected_socket [C268] Client called nw_connection_get_connected_socket on unconnected nw_connection
2019-09-30 17:59:36.379120+0800 kardashian[8997:267918] [] nw_socket_handle_socket_event [C269.1:1] Socket SO_ERROR [61: Connection refused]
2019-09-30 17:59:36.380715+0800 kardashian[8997:267918] [] nw_socket_handle_socket_event [C269.2:1] Socket SO_ERROR [61: Connection refused]
2019-09-30 17:59:36.381649+0800 kardashian[8997:267907] [] nw_connection_get_connected_socket [C269] Client called nw_connection_get_connected_socket on unconnected nw_connection
2019-09-30 17:59:38.395820+0800 kardashian[8997:267907] [] nw_socket_handle_socket_event [C270.1:1] Socket SO_ERROR [61: Connection refused]
2019-09-30 17:59:38.397339+0800 kardashian[8997:267907] [] nw_socket_handle_socket_event [C270.2:1] Socket SO_ERROR [61: Connection refused]

rrapiteanu commented 5 years ago

Possible solution: Check if your mac and phone are on the same wifi network lol :((.

facebook / react-native