axemclion/grunt-saucelabs

New Error: Could not connect to Sauce Labs API: Error: read ECONNRESET

Closed this issue · 31 comments

All our builds are failing with the following error now

Could not connect to Sauce Labs API: Error: read ECONNRESET

I am not quite sure where the error is coming from yet

I'm also experiencing this problem with 1 throttled option.

Still experiencing this problem? It could have been a temporary outage.

Could have been but what is really weird is, and that could be because of the SauceLabs API, all test would pass but the task would fail giving this message. I will keep testing to see if it's still occurring.

Ah, I think someone else encountered this and they submitted a PR we just merged. Try the newest version of grunt-saucelabs.

Thanks! Though debugging intermittent issues are always the most difficult

I'm running into the same issue myself while running tests. The new retry code should fix it, but I'll try to see whats up with the API...

Also seeing some weird ordering in the output. Not sure whether it indicates anything in particular:

 10 / 12 tests started
 11 / 12 tests started
=> Stopping Tunnel to Sauce Labs
 12 / 12 tests started
>> Could not connect to Sauce Labs API: Error: read ECONNRESET
Warning: Task "saucelabs-qunit:all" failed.� Use --force to continue.

Thanks. A bit less concerned about that one but could reveal something
interesting.

On Fri, Dec 12, 2014 at 3:11 PM, Chris Rebert notifications@github.com
wrote:

Also seeing some weird ordering in the output. Not sure whether it
indicates anything in particular:

10 / 12 tests started
11 / 12 tests started
=> Stopping Tunnel to Sauce Labs
12 / 12 tests started

Could not connect to Sauce Labs API: Error: read ECONNRESET
Warning: Task "saucelabs-qunit:all" failed. Use --force to continue.


Reply to this email directly or view it on GitHub
#174 (comment)
.

I'm having this problem too. Is it a server-side problem?

I'm going on the assumption that it is a server-side problem, and we're trying to nail down a simpler reproduction case.

Trying to narrow it down too. Will let you know what I find.

^.^

On Mon, Jan 5, 2015 at 11:58 AM, Laurent Goderre notifications@github.com
wrote:

Trying to narrow it down too. Will let you know what I find.


Reply to this email directly or view it on GitHub
#174 (comment)
.

Would be great if there was retry logic for this.. 🙏

There is a retry for timeout but not for this.

Exactly.

@cvrebert what about this: #175

The thing is since this basically an unhandled exception, there is no way to know what caused the issue. It just happens that for this bug retrying works but it's not guaranteed for all unhandled exceptions

@Jonahss I am not sure it would work because when the error occur it doesn't poll anymore

@Jonahss Ah! I'll give that a shot.

Is everyone who got this error using Sauce Connect tunnels?

I use tunnels and got this error.

Same here

Using Sauce Connect and also getting this error. Does seem to hit me when running >= 3 browsers or so. SauceLabs reporting The Sauce VMs failed to start the browser or device For more info, please check https://docs.saucelabs.com/reference/troubleshooting-common-error-messages/ in the interface despite the browsers I'm using being fully supported:

[
    {
        "browserName": "firefox",
        "platform": "Windows 8.1",
        "version": "15",
        "deviceName": ""
    },
    {
        "browserName": "chrome",
        "platform": "Windows 8.1",
        "version": "26",
        "deviceName": ""
    },
    {
        "browserName": "internet explorer",
        "platform": "Windows 8.1",
        "version": "11",
        "deviceName": ""
    },
    {
        "browserName": "firefox",
        "platform": "OS X 10.6",
        "version": "15",
        "deviceName": ""
    }
]

Feels as though one test encountered The Sauce VMs failed to start the browser or device For more info, please check https://docs.saucelabs.com/reference/troubleshooting-common-error-messages/ and the tunnel was immediately disconnected instead of allowing other tests to complete first.

Yeah, we should check the logic for closing tunnels, we should make sure the tunnel isn't closed until all tests have fully completed.

Shouldn't that be a separate issue though?

The error is different, but the way we handle tunnels might be responsible
for the same thing we see here.

On Thu, Jan 15, 2015 at 11:58 AM, Laurent Goderre notifications@github.com
wrote:

Shouldn't that be a separate issue though?


Reply to this email directly or view it on GitHub
#174 (comment)
.

Not sure, the suggested PR seems to be fixing this specific issue

See the discussion here. @gvas found that specific versions of Node.js cause issues.

This should be fixed in version 8.5.0

comment here if you still encounter ECONNRESET errors after updating.

Thanks everyone for the help!!