1

So what I'm noticing are random ETIMEDOUT errors at any point in a test (beg/med/end). There doesn't seem to be any rhyme or reason as to which tests this occurs on or when. The error I'm seeing is:

Failed: ETIMEDOUT connect ETIMEDOUT <ip>

The stack trace is: 

[chrome #01-3] ├--Spec completed
[chrome #01-3] ├--Failed assertions: 1
[chrome #01-3] ├----Failed: ETIMEDOUT connect ETIMEDOUT 52.0.174.230:4444
[chrome #01-3] ├----Error: ETIMEDOUT connect ETIMEDOUT 52.0.174.230:4444
[chrome #01-3]     at ClientRequest.<anonymous> (C:\dev\project\e2e\node_modules\selenium-webdriver\http\index.js:238:15)
[chrome #01-3]     at ClientRequest.emit (events.js:200:13)
[chrome #01-3]     at Socket.socketErrorListener (_http_client.js:410:9)
[chrome #01-3]     at Socket.emit (events.js:200:13)
[chrome #01-3]     at emitErrorNT (internal/streams/destroy.js:91:8)
[chrome #01-3]     at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
[chrome #01-3]     at processTicksAndRejections (internal/process/task_queues.js:84:9)

I've tried everything I can think of including different chrome options, changing AWSVPC settings, changing selenium hub/chrome docker versions, and changing the amount of tests that run in the cluster at any given time but all to no avail.

Using docker images selenium/hub:3.141.59 and same with chrome node selenium/node-chrome:3.141.59.

Any ideas on how to resolve this error?

Exziled
  • 473
  • 5
  • 20
  • it's possible AWS start new hub container one another instance to replace the previous container. thus the instance ip changed. – yong Aug 22 '19 at 14:28
  • @yong any idea how to get around this? Run the hub on a dedicated host? Or is there a way to publish to the chrome nodes that there's a new IP mid-test? I guess I hadn't thought of that but it seems 100% feasible that the underlying infrastructure is changing. – Exziled Aug 22 '19 at 14:34
  • I'm not sure it's possible to create a loader balancer ahead of the instances which hub container run inside, then create a route53 record target to the balancer, your test script confiure seleniumAdress to the route53 record. So you no need to concern instance ip change. – yong Aug 22 '19 at 14:46
  • @yong I am actually doing that already. I have an ALB in front of the ECS cluster that accepts traffic on port 4444 and directs all 4444 traffic to the cluster. My test config points to this ALB DNS url. However, maybe the fargate task is changing which server it runs on in the middle of a test and that chrome-node doesn't get the new IP until after the test completes? Will investigate that quickly. – Exziled Aug 22 '19 at 15:01
  • That doesn't seem to be related either, so still not sure what is causing these timeouts. – Exziled Aug 22 '19 at 15:07
  • It is possible that your webpage isn't loading completely in the container. If that happens and you try to access an element that isn't on the page, selenium will throw this error. – tanvi Aug 28 '19 at 16:07

0 Answers0