"socket hang up" on Nightwatch v1.0.14 mid-test

[lukasbach]

I am getting this error in 1.0.14. It seems mostly similar to #1788.

   POST  /wd/hub/session/d9ab872e5e220f21392bea9998a366e7/elements - ECONNRESET
       Error: socket hang up
     at createHangUpError (_http_client.js:322:15)
     at Socket.socketCloseListener (_http_client.js:363:25)
       Error while running .locateMultipleElements() protocol action: An unknown error has occurred.

The error always appears mid-test, after many instructions have been completed sucessfully. It appears at a random point during the test, and at that point all following nightwatch instructions fail with this error.

I am using nightwatch@1.0.14, chromedriver@2.44.0, chrome@70.0 on Windows 10 Enterprise (1709 Build 16299.785).

Edit: My nightwatch config looks like this: https://gist.github.com/lukasbach/f121ec9a4b7a7c337d2ebb0140476d37

[lukasbach]

@beatfactor Any idea what this could be caused by? I am getting this error both on my local testing setup as well as an CI setup (external linux based Jenkins server, which runs tests on a selenoid cluster).

[Deep27]

I've faced the same issue. Using Nightwatch v.1.0.17. When I updated chromedriver to 2.45 and google chrome to 71.0.3568.98, it's gone. I use Windows 7.

Here is my config:

{
  "src_folders": [
    "./app/src/test/tests/"
  ],
  "output_folder": "reports",
  "custom_commands_path": "./test/commands/",
  "custom_assertions_path": "./test/assertions/",
  "page_objects_path": [
    "./app_5_0/src/test/page_objects/"
  ],
  "globals_path": "./test/globals.js",
  "webdriver": {
    "start_process": true,
    "server_path": "dev\\drivers\\windows\\chromedriver-2.45.exe",
    "port": 9515
  },
  "test_settings": {
    "default": {
      "skip_testcases_on_fail": false,
      "launch_url": "http://localhost:8081",
      "silent": true,
      "desiredCapabilities": {
        "browserName": "chrome",
        "acceptSslCerts": true,
        "acceptInsecureCerts": true,
        "javascriptEnabled": true
      }
    }
  }
}

[StephanBijzitter]

I'm getting the same with Firefox, also in the middle of a test run.

Mac OS X Firefox 64 Geckodriver 0.23.0 (webdriver) Nightwatch 1.0.18

  "webdriver": {
    "port": 4444,
    "start_process": true,
    "server_path": "node_modules/selenium-standalone/.selenium/geckodriver/0.23.0-x64-geckodriver"
  },

1546427699040   mozrunner::runner   INFO    Running command: "/Applications/Firefox.app/Contents/MacOS/firefox-bin" "-marionette" "-foreground" "-no-remote" "-profile" "/var/folders/b1/r9rt0f054g585pw0thgyc_z80000gn/T/rust_mozprofile.shTTVKiBEw3O"
1546427699489   addons.webextension.screenshots@mozilla.org WARN    Loading extension 'screenshots@mozilla.org': Reading manifest: Invalid host permission: resource://pdf.js/
1546427699489   addons.webextension.screenshots@mozilla.org WARN    Loading extension 'screenshots@mozilla.org': Reading manifest: Invalid host permission: about:reader*
Can't find symbol 'GetGraphicsResetStatus'.
1546427700828   Marionette  INFO    Listening on port 58759
JavaScript warning: https://d2j6bcwbysm0gv.cloudfront.net/mobile.45af4a1979f5b984e66491686ad4ca6f.js, line 14: unreachable code after return statement
JavaScript warning: https://d2j6bcwbysm0gv.cloudfront.net/mobile.45af4a1979f5b984e66491686ad4ca6f.js, line 14: unreachable code after return statement
JavaScript warning: https://d2j6bcwbysm0gv.cloudfront.net/mobile.45af4a1979f5b984e66491686ad4ca6f.js, line 14: unreachable code after return statement
JavaScript warning: https://d2j6bcwbysm0gv.cloudfront.net/mobile.45af4a1979f5b984e66491686ad4ca6f.js, line 14: unreachable code after return statement
1546427720021   Marionette  INFO    Stopped listening on port 58759
1546427720480   mozrunner::runner   INFO    Running command: "/Applications/Firefox.app/Contents/MacOS/firefox-bin" "-marionette" "-foreground" "-no-remote" "-profile" "/var/folders/b1/r9rt0f054g585pw0thgyc_z80000gn/T/rust_mozprofile.vAE7WL9bnX32"
1546427720925   addons.webextension.screenshots@mozilla.org WARN    Loading extension 'screenshots@mozilla.org': Reading manifest: Invalid host permission: resource://pdf.js/
1546427720925   addons.webextension.screenshots@mozilla.org WARN    Loading extension 'screenshots@mozilla.org': Reading manifest: Invalid host permission: about:reader*
Can't find symbol 'GetGraphicsResetStatus'.
1546427722232   Marionette  INFO    Listening on port 58929
console.error: BroadcastService: 
  receivedBroadcastMessage: handler for
  remote-settings/monitor_changes
  threw error:
  Message: Error: Polling for changes failed: NetworkError when attempting to fetch resource..
  Stack:
    remoteSettingsFunction/remoteSettings.pollChanges@resource://services-settings/remote-settings.js:750:13

Sidenote: start_process also doesn't work, I still have to start it manually

[lukasbach]

Update: The problem does still occur for me on the earliest version of nightwatch, 1.0.18 (chromedriver 2.45.0, selenium-server 3.141.59, Google Chrome 71.0.3578.98).

[marian-r]

I've faced this error, when testing for new tab being opened and trying to get URL or page elements too quickly before the page is loaded. The following fails:

browser.url('http://localhost/test.html')
    .waitForElementPresent('a')
    .click('a')
    .windowHandles(result => {
      browser
          .switchWindow(result.value[1])
          .assert.urlContains('https://www.example.com');
    })
    .end();

But adding a 1s pause resolves it:

browser.url('http://localhost/test.html')
    .waitForElementPresent('a')
    .click('a')
    .windowHandles(result => {
      browser
          .switchWindow(result.value[1])
          .pause(1000) // Let's pause for a sec.
          .assert.urlContains('https://www.example.com');
    })
    .end();

[venkata-018]

facing same issue with 500 post error with "selenium-download": "2.0.13", "selenium-server-standalone-jar": "3.141.5", "selenium-standalone": "6.15.4", "chromedriver": "2.45.0", Response 500 POST /wd/hub/session/d9bc44a9a748a07cdf8cb15aace10797/element/0.2789049356657476-21/elements (16ms) { value: { error: [], message: 'java.net.SocketException: Connection reset by peer (connect failed)' }, status: 13 } Error while running .locateMultipleElementsByElementId() protocol action: java.net.SocketException: Connection reset by peer (connect failed)

Response 500 POST /wd/hub/session/d9bc44a9a748a07cdf8cb15aace10797/element/0.2789049356657476-23/elements (121ms) { value: { error: [], message: 'java.net.SocketException: Connection reset by peer (connect failed)' }, status: 13 } Please help me get rid of this error.. Error while running .locateMultipleElementsByElementId() protocol action: java.net.SocketException: Connection reset by peer (connect failed

[Deep27]

After we started using Moon for parallel tests, again, we had the same "socket hang up" error.

  ...
  "test_settings": {
    "default": {
      "request_timeout_options": {
        "timeout": 100000
      },
      ...

Adding timeout with enough large value helped to solve the problem. (Moon 1.3.3, NightwatchJS 1.0.17)

[Kushagra8888]

I am not able to reliably reproduce the error. The same tests would sometimes throw this error and sometimes don't. Regardless, it does not affect the outcome of the test.

In my particular case it happens when there's a spinner on the screen and I am waiting for the an element to be present. Have tried the expect as well as the chained command flavours of tests and that does not seemed to have an effect.

[vkyt]

Running into the same issue with latest chromedriver@74.0.0 and nightwatch v1.0.19 In my case I'm running into socket hang up error a lot at browser.url(my_url) and browser.deleteCookies()

    POST  /session/cf3823f14a1b3462130539955c273235/url - ECONNRESET
Error: socket hang up
    at createHangUpError (_http_client.js:342:15)
    at Socket.socketCloseListener (_http_client.js:377:23)
 Error while running .navigateTo() protocol action: An unknown error has occurred.

   Request DELETE  /session/bc8c44f9e390f9416559c6a9c1bae809/cookie
    DELETE  /session/bc8c44f9e390f9416559c6a9c1bae809/cookie - ECONNRESET
Error: socket hang up
    at createHangUpError (_http_client.js:342:15)
    at Socket.socketCloseListener (_http_client.js:377:23)
 Error while running .deleteAllCookies() protocol action: An unknown error has occurred.

[aberonni]

+1 having the same issue sporadically - not able to reproduce consistently

[beatfactor]

How about the workaround that @Deep27 suggested?

[eponymz]

Seeing this as well more often than not. I will try the workaround, but when time is of the essence it isn't optimal to make the tests take longer. Is there a root cause known? Seeing this when running with test_workers on Nightwatch v1.0.19, Chrome v74.0.3729.169, chromedriver v2.46.0

[aberonni]

The workaround partially mitigates but does not totally eradicate the issue - testing with the latest nightwatch version. https://github.com/nightwatchjs/nightwatch/issues/1936#issuecomment-453542717 this seems to be the closest to reproducing it but still not enough info (and I can't reproduce in isolation).

This also is confirmed a regression with v1 - did not happen with older versions.

[kiran-ghe]

I updated the chrome version to 75.0.1 and somehow I don't see this issue on my machine anymore.

[edwardxia]

For anyone who is running in to this, I can tell this is a network issue and I have a reliable re-pro described in #2147. However, I get different behavior on CentOS vs Ubuntu. It would be helpful for whoever running into this issue to report:

1. Is it only 1 operation fail, or all operations after it fails.
2. What kind of OS and version you're running.

[aberonni]

I think there might be more than one issue here. I don't think it is necessarily always a network issue, simply because this didn't seem to be happening on older versions.

If somehow it is connected to the network issue, it means that in older versions of nightwatch this was somehow handled gracefully.

[LoganBarnett]

My team has been running into this issue during a package upgrade endeavor. We downgraded Nightwatch to the last known working version for us (1.0.19) and still encountered the error. Downgrading Node to a prior version (10.7.0) fixed the issue.

I'm not sure which versions will also work - we're trying to figure that out now. I'm also not sure how Node is involved in the issue yet (do newer Node versions have a bug, or is there some change that Nightwatch hasn't accounted for?). I'll post again when I have more information.

[LoganBarnett]

This problem manifests between Node 10.15.0 (working) and 10.15.1 (breaking). With the delta in the changelog, I'm not surprised that a patch version caused the break. It may take some digging to figure out what changed that couldn't caused this issue in Nightwatch though. I've upgraded Nightwatch as part of this test as well and the breaking/working is consistent with Node versions.

[beatfactor]

@LoganBarnett thanks for your insights. Can you tell us which OS platform your team is using to run the tests? And if you don't mind too much, it would be awesome if you could tell us a little bit about your project here: https://github.com/nightwatchjs/nightwatch/issues/2154

[LoganBarnett]

@beatfactor Our test suite is running on the Docker Node.JS image as a base. So in that sense, it's a Debian based Linux.

This is our Dockerfile:

FROM node:10.15.0

ARG UID=<REDACTED>
ARG GID=<REDACTED>
ARG USER=<REDACTED>

USER root

RUN (groupadd $USER -g $GID || true) \
    && (useradd -Nlm $USER -g $GID -u $UID || true)

# Work around for https://github.com/nodejs/docker-node/issues/1013 (adapted from an example in the comments)
RUN echo "deb http://deb.debian.org/debian jessie main" > /etc/apt/sources.list
RUN echo "deb http://security.debian.org jessie/updates main" >> /etc/apt/sources.list
RUN apt-get update

# seems to be needed to properly install chromedriver
RUN apt-get install -y libnss3

# chrome - instructions from https://www.linuxbabe.com/desktop-linux/how-to-install-google-chrome-on-debian-the-easy-way
RUN curl -sL https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -
RUN echo "deb http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list
RUN apt-get update
RUN apt-get install -y google-chrome-stable

# upgrade yarn version: from https://github.com/nodejs/docker-node/blob/master/docs/BestPractices.md#upgradingdowngrading-yarn
ENV YARN_VERSION 1.15.2
RUN curl -fSLO --compressed "https://yarnpkg.com/downloads/$YARN_VERSION/yarn-v$YARN_VERSION.tar.gz" \
    && tar -xzf yarn-v$YARN_VERSION.tar.gz -C /opt/ \
    && ln -snf /opt/yarn-v$YARN_VERSION/bin/yarn /usr/local/bin/yarn \
    && ln -snf /opt/yarn-v$YARN_VERSION/bin/yarnpkg /usr/local/bin/yarnpkg \
    && rm yarn-v$YARN_VERSION.tar.gz

USER <REDACTED>

As for #2154, I left a comment some weeks back here, but I'm happy to add more to it if you feel like that's useful :)

For more notes on reproduction, I've seen tests work when we run just one on our local machines (latest MacOS). I suspect it needs to have something long-running enough to trigger the issue, but I don't make this claim with certainty. Of course as I find out more I'll chime in.

[MicahLC]

I had been seeing this same ECONNRESET Error: socket hang up failure other people have mentioned here. Our tests were running using Nightwatch v1.2.3, Node v8.6.0, on a local Jenkins instance against BrowserStack. I did not see these errors at all until we started running our Nightwatch tests on BrowserStack. The error was inconsistent and didn't always occur even on the same test file/test case, but I did observe that we only saw it on our two slower/weaker Jenkins nodes, not our beefier master node.

I tried the workaround mentioned here, and also updated the Node version we are using to be 10.15.3 (what our app runs and what we all use locally), and I'm seeing a similar but slightly different error, presumably because it's trying to reconnect. I've got a gist here that's got the verbose Nightwatch logs, starting with the command that failed and including all the things afterwards (properly redacted, of course :) ). In a nutshell, I'm now seeing GET http://hub-cloud.browserstack.com /wd/hub/session/55f8fd202cd87e4fd14f911279e80811a7939116/source - ETIMEDOUT in the logs. On the BrowserStack side, they never received that final command that timed out (unsurprisingly) or anything afterwards, and the session timed out 90 seconds later.

@beatfactor, or whoever else investigates this: lmk if there's any more information I can share. I can try to redact my nightwatch configuration file and share it, if that's helpful.

[LoganBarnett]

@MicahLC can you force your environments to all use Node 10.15.0 to see if that clears it up? Once you hit 10.15.1 or higher you should see this issue manifest (I see you at 10.15.3 from your post). I would be highly suspect of differences in your Jenkins nodes vs. master, which I suggest addressing with logging the node version. I'm not familiar with BrowserStack but if it's using a Node version it would be good to confirm the node version there as well if possible.

From your gist I didn't see the socket hangup message that this thread began about. It could be your issue isn't the same, but still warrants looking into.

[aberonni]

Just to add more info to the thread. I seem to have successfully got rid of the error by using (almost) the same Dockerfile as provided by @LoganBarnett here

That said, I was still reproducing the error with node 10.15.0 installed on top of the selenium-chrome docker images. I had something along these lines:

FROM selenium/standalone-chrome:3.141.59-uranium

USER root

RUN sudo apt-get -yqq update

# Install node
RUN curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash -
RUN sudo apt-get -yqq install nodejs
# Installing a specific version with n to deal with
# https://github.com/nightwatchjs/nightwatch/issues/1936#issuecomment-522795228
RUN npm install -g n
# https://www.npmjs.com/package/n#installing-node-versions
RUN n 10.15.0

# Install yarn
RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
RUN sudo apt-get -yqq update
RUN sudo apt-get -yqq install yarn

ADD start.sh /start.sh
RUN chmod 755 /start.sh

ENTRYPOINT ["/start.sh"]

start.sh:

#!/bin/bash

set -e

echo "Starting Chrome Webdriver service"
mkdir -p /var/log/chromedriver
/usr/bin/chromedriver --port=4444 --url-base=/wd/hub --log-path=/var/log/chromedriver/chromedriver.log &

/bin/bash

I didn't have the chance to test things separately, but another change I made was to get rid of my start.sh file and just let nightwatch manage chromedriver directly. I don't know whether this change has also had an impact on fixing the issue.

[LoganBarnett]

@aberonni Can you add some logging somewhere in your setup that prints the node version? The closer you can get this to your runtime the better (I don't really see in your code where you actually start nightwatch). Perhaps the best case is check from the node runtime itself as it runs nightwatch, from your nightwatch.config.js or similar file with something like this:

console.log(`Node version: ${process.version}`)

doc ref for process.version

I say this because my understanding is n <version> tells n to install a node version, but I'm not sure that subsequent statements will actually use that version - especially since each RUN in Docker is a new shell instance. If your setup is allowing some downstream process to run inside the Docker context (my familiarity with the Docker jargon breaks down here), it may be that whatever n has configured is not actually running the node version you expect. Light poking around the nodejs Debian distribution sources implies that it will install version 12, but even if it installs version 10 one would think this would be the latest patch version - both of which would continue to cause the break you're seeing in selenium/standalone-chrome:3.141.59-uranium. I could be totally off of course, but it would be great to confirm one way or another.

[gupta01sunil]

@beatfactor Or Any one who is working on the socket exception. We are facing the Socket exception issue in Nightwatch v1.2.4 Chrome Driver:2.43 in Windows 7. Node v12.12.0

POST /wd/hub/session - ECONNRESET Error: socket hang up at connResetException (internal/errors.js:570:14) at Socket.socketCloseListener (_http_client.js:380:25) Error: An error occurred while retrieving a new session: "socket hang up" at Socket.socketCloseListener (_http_client.js:380:11)

[gupta01sunil]

@beatfactor Or Any one who is working on the socket exception. I want to know which is the stable version of Nightwatch JS and its corresponding NodeJS versions. Please help on the npm commands to switch to the stable versions in Windows environment.

[apurvanataraj88]

   Error: Timeout while trying to connect to ChromeDriver on port 9515.
       at Socket.socketErrorListener (_http_client.js:406:9)
       at emitErrorNT (internal/streams/destroy.js:92:8)
       at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
       at processTicksAndRejections (internal/process/task_queues.js:80:21)

This is what I am seeing even before a test starts to run. My chromeDriver is at 77.0.0 and desiredCapabilities are also defined for Chrome.

[gkim795]

Similarly experiencing an error socket hang up sporadically when refreshing a page in my tests

 browser.pause(1000).refresh(() => {
          browser
            .pause(1000)
            .waitForElementVisible(ITEM)
        });

receiving the error below

POST http://selenium-platform:4444 /wd/hub/session/314e048241cc64c8bdeea871641bc75e/refresh - ECONNRESET | 75s
-- | --
57 | Error: socket hang up | 75s
58 | at createHangUpError (_http_client.js:323:15) | 75s
59 | at Socket.socketCloseListener (_http_client.js:364:25) | 75s
60 | Error while running .pageRefresh() protocol action: An unknown error has occurred.

Library	Version
NightwatchJS	v1.2.4
Chromedriver	79.0.0

[apurvanataraj88]

It was a GasMask issue. 🤦‍♂ I had another config file open through GasMask that was preventing a local session from launching.

[dombialcz]

I have a similar issue, but not mid-test, just something like #1788 When launching nightwatch with chromedriver - chrome windows is opened but nightwatch never connects resulting in econ refused. I am using

nightwatch . 1.3.2 chromedriver: 79.0.0

What's interesting - everything works fine, until I open a connection using VPN FortiClient. Firefox and Safari work without any issues, but I need chrome for testing and I need to be connected via VPN. Mac OS Catalina 10.15.1

nightwatch % ./node_modules/.bin/nightwatch node_modules/nightwatch/examples/tests/ecosia.js --env chrome

[Ecosia.org Demo] Test Suite
============================
⠹ Connecting to localhost on port 4444...
    POST  /session - ECONNRESET
Error: socket hang up
    at connResetException (internal/errors.js:570:14)
⚠ Error connecting to localhost on port 4444.
_________________________________________________

TEST FAILURE: 1 error during execution; 0 tests failed, 0 passed (1m 0s)

 ✖ ecosia

  Error: An error occurred while retrieving a new session: "socket hang up"
       at Socket.socketCloseListener (_http_client.js:380:11)

   SKIPPED:
   - Demo test ecosia.org

Okay my problem was resolved, I think the issue was with chromedriver mixing up port and ip address, and this - I think - was caused by VPN client for some reason. Changes I made that resulted in this working were only two:

• DO NOT tick 'akways up' on VPN client when connecting - this is probably specific to FortiClient VPN
• enable verbose logs on chromedriver (but disabling them now doesnt affect the tests)

In the working version I can see: [1577226137.104][INFO]: resolved localhost to ["127.0.0.1","::1"]

In the conn refused version I can see: [1577225248.636][INFO]: resolved localhost to ["::1","127.0.0.1"] [1577225250.618][WARNING]: Timed out connecting to Chrome, retrying... [1577225250.620][INFO]: resolved localhost to ["::1","127.0.0.1"] [1577225254.620][WARNING]: Timed out connecting to Chrome, retrying... [1577225254.620][INFO]: resolved localhost to ["::1","127.0.0.1"] [1577225262.621][WARNING]: Timed out connecting to Chrome, retrying... [1577225262.626][INFO]: resolved localhost to ["::1","127.0.0.1"] [1577225278.622][WARNING]: Timed out connecting to Chrome, giving up. chromedriver.log chromedriverWORKING.log

[alien0matic]

I had the same problem like dombialcz, unfortunately the "always up" option wasn't present in my FortiClient. I noticed the IPv6 address was always the first in the webdriver log. It turned out that the FortiClient breaks the IPv6 protocol and you can't even ping ::1 anymore. So I removed the entry for ::1 localhost from the /etc/hosts file (I'm on a Mac) and the tests are working again.

[dwpull]

Hi guys, I have similar or same issue. When running node nightwatch -e chrome -a google

I get `i Connected to 127.0.0.1 on port 4444 (3778ms). Using: chrome (81.0.4044.122) on Windows NT platform.

Running: Google demo test

Error while running .navigateTo() protocol action: unknown error: Runtime.executionContextCreated has invalid 'context': {"auxData":{"frameId":"FDC3E816F252E59194C0341D58D777CE","isDefault":true,"type":"default"},"id":1,"name":"","origin":"://"}

Response 500 POST /wd/hub/session/9bd22e708c5a4546174c996fd4a8235a/elements (2265ms) { value: { error: [], message: 'java.net.ConnectException: Connection refused: connect' }, status: 13 } Error while running .locateMultipleElements() protocol action: java.net.ConnectException: Connection refused: connect

Response 500 POST /wd/hub/session/9bd22e708c5a4546174c996fd4a8235a/elements (2327ms) { value: { error: [], message: 'java.net.ConnectException: Connection refused: connect' }, status: 13 }

[kretschmannj]

I have a similar issue, but not mid-test, just something like #1788 When launching nightwatch with chromedriver - chrome windows is opened but nightwatch never connects resulting in econ refused. I am using

nightwatch . 1.3.2 chromedriver: 79.0.0

What's interesting - everything works fine, until I open a connection using VPN FortiClient. Firefox and Safari work without any issues, but I need chrome for testing and I need to be connected via VPN. Mac OS Catalina 10.15.1

nightwatch % ./node_modules/.bin/nightwatch node_modules/nightwatch/examples/tests/ecosia.js --env chrome

[Ecosia.org Demo] Test Suite
============================
⠹ Connecting to localhost on port 4444...
    POST  /session - ECONNRESET
Error: socket hang up
    at connResetException (internal/errors.js:570:14)
⚠ Error connecting to localhost on port 4444.
_________________________________________________

TEST FAILURE: 1 error during execution; 0 tests failed, 0 passed (1m 0s)

 ✖ ecosia

  Error: An error occurred while retrieving a new session: "socket hang up"
       at Socket.socketCloseListener (_http_client.js:380:11)

   SKIPPED:
   - Demo test ecosia.org

Okay my problem was resolved, I think the issue was with chromedriver mixing up port and ip address, and this - I think - was caused by VPN client for some reason. Changes I made that resulted in this working were only two:

• DO NOT tick 'akways up' on VPN client when connecting - this is probably specific to FortiClient VPN
• enable verbose logs on chromedriver (but disabling them now doesnt affect the tests)

In the working version I can see: [1577226137.104][INFO]: resolved localhost to ["127.0.0.1","::1"]

In the conn refused version I can see: [1577225248.636][INFO]: resolved localhost to ["::1","127.0.0.1"] [1577225250.618][WARNING]: Timed out connecting to Chrome, retrying... [1577225250.620][INFO]: resolved localhost to ["::1","127.0.0.1"] [1577225254.620][WARNING]: Timed out connecting to Chrome, retrying... [1577225254.620][INFO]: resolved localhost to ["::1","127.0.0.1"] [1577225262.621][WARNING]: Timed out connecting to Chrome, retrying... [1577225262.626][INFO]: resolved localhost to ["::1","127.0.0.1"] [1577225278.622][WARNING]: Timed out connecting to Chrome, giving up. chromedriver.log chromedriverWORKING.log

Interesting. I have the opposite problem. If I have my VPN turned off then I get a connection timeout error when trying to run against Chrome. However, as soon as I enable VPN then I can run the tests on Chrome no problem.

[kretschmannj]

Any updates on this? I posted the last message re: VPN and that was indeed an issue with our VPN set-up and it has now been resolved. However, just today I'm seeing another issue related to the initial post about the socket hangup error ... → Running command: url ('http://qa.dc-pbm.com/', ) Request POST /session/25573b4e-3d74-40de-9866-7ff8965e7354/url
{ url: 'http://qa.dc-pbm.com/' } POST /session/25573b4e-3d74-40de-9866-7ff8965e7354/url - ECONNRESET Error: socket hang up at createHangUpError (_http_client.js:323:15) at Socket.socketCloseListener (_http_client.js:364:25) Error while running .navigateTo() protocol action: An unknown error has occurred. I'm running:

• node v10.16.0
  • nightwatch v1.3.4
  • Linux 3.10.0-1062.18.1.el7.x86_64
  • Firefox 68.6.0
  • geckodriverVersion': '0.26.0

[UtechtDustin]

I get the same error with the following configuration:

node: 14.4.0 nightwatch 1.3.6 Linux 5.4.0-37-generic Chromedriver: 83.0.0

[lajuffermans]

Same issue here since we migrated from nightwatch 0.9.20 to 1.3.6 and it doesn't always happen:

• node: 10.21.0
• nigthwatch: 1.3.6
• chromedriver: 83.0.0

An error occurred while retrieving a new session: "socket hang up"

      Error: An error occurred while retrieving a new session: "socket hang up"
    at Selenium2Protocol.handleSessionCreateError 
    at HttpRequest.request.on.err 
    at emitOne (events.js:116:13)
    at HttpRequest.emit (events.js:211:7)
    at ClientRequest.originalIssuer.on.args 
    at emitOne (events.js:121:20)
    at ClientRequest.emit (events.js:211:7)
    at Socket.socketCloseListener (_http_client.js:377:9)
    at emitOne (events.js:121:20)
    at Socket.emit (events.js:211:7)

[marian-r]

I think I've found the root cause and created #2455 to fix it.

I've discovered that the error occurs after the request for creating session times out. This case is handled properly at the test suite start, but not for during individual tests. If one test closes session using client.end() it has to be recreated at the beginning of another test. If the request times out there, error is unhandled and may result in tests not starting and/or being not reported as failed.

[Pieras2]

Which NW version will carry the fix? I get the socket hangups on AzureDevops - on NW 1.3.4 on chrome (84), while with NW 1.3.7 more often on firefox :/

[drabelo]

Is this issue being addressed?

[RichMatthews]

I'm getting this issue too, would be good to know if it's getting progressed

[beatfactor]

Yes, a fix will be released in the next version, which is already in master and should be available in NPM by early next week.

[Pieras2]

Cool 👌🏻

czw., 27 sie 2020, 13:57 użytkownik Andrei Rusu notifications@github.com napisał:

Yes, a fix will be released in the next version, which is already in master and should be available in NPM by early next week.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nightwatchjs/nightwatch/issues/1936#issuecomment-681902359, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMUVMH3OSGPYXA35VCPZ2ZTSCZCZRANCNFSM4GGT7BWQ .

[drabelo]

Perfect! Thank you :) 🙏

[RichMatthews]

@beatfactor do you know if this is now fixed and what version of Nightwatch we should upgrade to?

[beatfactor]

It’s fixed in 1.4, which is in master already and will be published later today.

On Fri, 4 Sep 2020 at 14:16, Rich Matthews notifications@github.com wrote:

@beatfactor https://github.com/beatfactor do you know if this is now fixed and what version of Nightwatch we should upgrade to?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nightwatchjs/nightwatch/issues/1936#issuecomment-687106982, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADGNMQWLRV7UXZWFEQ2TY3SEDLCVANCNFSM4GGT7BWQ .

[shreev1]

this issue is there in 1.3.6 and 1.4.3 while not in 0.9.12 (that is quiet old version to use) Please advise

[Pieras2]

unfortunately I switched to 1.4.3 counting that no more hangup will happen on Azure devops but unfortunately I caught it too :(

[beatfactor]

this issue is there in 1.3.6 and 1.4.3 while not in 0.9.12 (that is quiet old version to use) Please advise

@shreev1 Can you elaborate on the kind of errors you have been seeing? Have you set timeout_options to retry the aborted http requests – this doesn't happen by default, maybe we'll add retries as default in future versions..

[VikasGhorpade]

I am also facing same issue like socket hang up error: POST /wd/hub/session/685536c4130398c484012ff61549e6bf/elements - ECONNRESET Error: socket hang up at createHangUpError (_http_client.js:342:15) at Socket.socketOnEnd (_http_client.js:437:23) at endReadableNT (_stream_readable.js:1064:12) at _combinedTickCallback (internal/process/next_tick.js:139:11) at process._tickDomainCallback (internal/process/next_tick.js:219:9) Error while running .locateMultipleElements() protocol action: An unknown error has occurred.

I tested with nightwatch 1.3.6, 1.4.3 and 1.5.0 as well but issue is still reproducible and it appears in between execution of tests in parallel. I tried by increasing the request_timeout_option as well but did not help: "request_timeout_options": { "timeout": 120000 },

in which version this issue will be fixed?

[kretschmannj]

I also get this error when running in parallel. Last update was two months ago. Any update?