christian-bromann
commented
5 years ago Can you provide a PR with a similar fix as for v5?
Closed osmolyar closed 5 years ago
christian-bromann
commented
5 years ago Can you provide a PR with a similar fix as for v5?
osmolyar
commented
5 years ago @christian-bromann , a PR with a similar fix for v5 was provided in https://github.com/webdriverio-boneyard/v4/pull/25 as requested above, but it didn't fix the issue. (Also tried printing out newOptions.headers as suggested in the context of https://github.com/webdriverio/webdriverio/pull/3600, but there didn't seem to be any issue with the headers immediately before or after the error.)
Here is zip file to reproduce the issue using a non-proprietary page, Google Search, and have narrowed it down to the fact that the browser.reload() command must get called (every scenario, as in the original, or a few times a scenario as in the attached zip). google_search_reproduce_socket_hangup_with_isc_folders.zip
(command to run: 'wdio config\wdio.conf.js --suite search - error occurs on 1st, 2nd or 3rd TC)
However, bizarrely, it's not reproduced with the same exact feature file, code and config file in this. more minimal zip file (lacking some folders that are not being referenced or used) google_search__no_reproduce_socket_hang_up.zip
osmolyar
commented
5 years ago Finally got the issue; it was the mere presence of a step definition file that contained this line
var req = http.request(testConfig.config.httpOptions, callback);
at the beginning of the file (rather than within a step definition) that was causing the issue, even if no steps defined in the file were being run.
Closing the issue. Thanks all for the help.
(This is a resubmit of https://github.com/webdriverio/webdriverio/issues/3460, erroneously filed under webdriverio master. Resubmitting here as it pertains to v4.)
The following 'socket hang up' error occurs on different steps starting on the 8th to 11th scenario in a given feature file, where the previous scenarios, usually with the same sequence of steps as the failing one, run fine. Up until last November, all were running fine and passing, for ~1yr.
The subsequent 4 tests also fail with 'socket hang up', while the following few tests will fail with error 'A session id is required for this command but wasn't found in the response payload', and then will start passing again.
A new session is started with each scenario, as browser.reload() gets called on starting a scenario. The initial 'socket hang up' error occurs usually 4-5 steps into the scenario, while subsequent ones occur on the first step of the scenario.
This is on Chrome, and was working perfectly until ~last November. Similar intermittent 'A session id is required for this command but wasn't found in the response payload' errors had always occurred on IE10 and IE11 (with no 'socket hang up').
Concurrent with the error, a browser window gets opened but doesn't get resized or attempt to navigate to the application url, and stays open while new windows get generated for new scenarios.
It happens with every feature file run, both using selenium-standalone locally, wdio testrunner and Selenium Grid Extras via Jenkins.
"Error: socket hang up at createHangUpError (_http_client.js:302:15) at Socket.socketOnEnd (_http_client.js:394:23) at emitNone (events.js:91:20) at Socket.emit (events.js:186:7) at endReadableNT (_stream_readable.js:974:12) at _combinedTickCallback (internal/process/next_tick.js:74:11) at process._tickDomainCallback (internal/process/next_tick.js:122:9)"
Environment (please complete the following information):
selenium-standalone 3.141.0
Additional context Add any other context about the problem here.
With chromedriver versions <=2.43, the following concurrent error also occurs in the selenium log as noted below, with trace: "java.lang.IllegalStateException: Committed".
With chromedriver 2.45, the same 'Socket hang up' error occurs as the step error in the wdio output, but the java.lang.illegalStateException: Committed is not output, and instead the selenium-standalone log shows multiple sessions created and removed without intervening output, as follows:
Starting ChromeDriver 2.45.615291 (ec3682e3c9061c10f26ea9e5cdcf3c53f3f74387) on port 42068 Only local connections are allowed. 15:51:45.018 INFO [ProtocolHandshake.createSession] - Detected dialect: OSS 15:51:45.033 INFO [RemoteSession$Factory.lambda$performHandshake$0] - Started new session ee949d62bb60cec80c97246fe5f21c13 (org.openqa.selenium.chrome.ChromeDriverService) 15:51:45.506 INFO [ProtocolHandshake.createSession] - Detected dialect: OSS 15:51:45.538 INFO [RemoteSession$Factory.lambda$performHandshake$0] - Started new session ff3758d7f2582b39ee02e3f6657ebabd (org.openqa.selenium.chrome.ChromeDriverService) 15:51:46.887 INFO [ProtocolHandshake.createSession] - Detected dialect: OSS 15:51:46.921 INFO [RemoteSession$Factory.lambda$performHandshake$0] - Started new session 40e0db5140996cd8a2e044f1901aeea6 (org.openqa.selenium.chrome.ChromeDriverService) 15:51:52.438 INFO [ActiveSessions$1.onStop] - Removing session
This corresponds to logger output of messages being logged in before and after-scenario hooks, like
"in beforeScenario in afterScenario in beforeScenario in afterScnenario"
without intervening logging, which normally occurs while a scenario is executed. (The 'Socket hang up' error is output at then end of the run, as the Step/scenario error trace).
Here is a zip file to reproduce the issue against google.com:
google_search_reproduce_socket_hangup_with_isc_folders.zip
(command to run: 'wdio config\wdio.conf.js --suite search - error occurs on 1st, 2nd or 3rd TC)
However, bizarrely, it's not reproduced with the same exact feature file, code and config file in this. more minimal zip file (lacking some folders that are not being referenced or used)
google_search__no_reproduce_socket_hang_up.zip
Allure-report.zip where, if you filter out all passing and failed TCs, you can see each feature file with >9 scenarios hits the 'socket hang up' at TC8,9,10,11 or12: allure-report.zip