cypress-io / cypress

Fast, easy and reliable testing for anything that runs in a browser.
https://cypress.io
MIT License
47.11k stars 3.19k forks source link

Performance issues to connect to Cypress Dashboard when behind a proxy #28423

Open Roemer opened 12 months ago

Roemer commented 12 months ago

Current behavior

When running Cypress behind a corporate proxy, there is always a 1 minute overhead for each Cypress run when connecting to the Cypress Dashboard. The problem seems to be the "preflight" request, which first tries to connect to api-proxy.cypress.io without the system-wide defined proxy and then after 1 minute, it tries api.cypress.io with the correct proxy which then responds immediately.

Desired behavior

No response

Test code to reproduce

This is a bit harder to reproduce easily. You need a setup where internet access is blocked unless a specific proxy is used, then define this proxy as http_proxy and https_proxy environment variable and run Cypress.

Cypress Version

13.5.0

Node version

v18.17.1

Operating System

Docker Container (Debian)

Debug Logs

cypress:server:cloud:api request to url: POST https://api-proxy.cypress.io/preflight with params: {"body":{"apiUrl":"https://api.cypress.io/","dependencies":{},"errors":[],"projectId":"xxx","ciBuildId":"rbl-test-05","testingType":"e2e","parallel":true},"headers":{"x-route-version":"1","x-cypress-request-attempt":0,"x-os-name":"linux","x-cypress-version":"13.5.0"}} and token: undefined +0ms

--------- Lots of process_profiler entries

cypress:server:cloud:api request to url: POST https://api.cypress.io/preflight with params: {"body":{"apiUrl":"https://api.cypress.io/","dependencies":{},"errors":[],"projectId":"xxx","ciBuildId":"rbl-test-05","testingType":"e2e","parallel":true},"headers":{"x-route-version":"1","x-cypress-request-attempt":0,"x-os-name":"linux","x-cypress-version":"13.5.0"}} and token: undefined +1m
cypress:network:agent addRequest called { isHttps: true, href: 'https://api.cypress.io/preflight' } +0ms
cypress:network:agent got family { family: undefined, href: 'https://api.cypress.io/preflight' } +1ms
cypress:network:agent Creating proxied socket for https://api.cypress.io/preflight through http://myproxy:3128 +3ms
cypress:network:connect successfully connected { opts: { port: 3128, host: 'myproxy', useTls: false, getDelayMsForRetry: [Function (anonymous)] }, iteration: 0 } +0ms
cypress:network:agent Proxy socket for https://api.cypress.io/preflight established +9ms
cypress:server:cloud:api response { apiUrl: 'https://api.cypress.io/', encrypt: false } +415ms

Other

No response

Roemer commented 12 months ago

I created a MR which potentially fixes this issue here: https://github.com/cypress-io/cypress/pull/28340

jennifer-shehane commented 12 months ago

We had some reports previously that running Cypress was slower when connected to the Cloud, but we were unable to reproduce it at the time. We'll take a look.

Roemer commented 10 months ago

Any news here? The issue is visible by using a local proxy (eg. Fiddler) and redirecting cypress to Fiddler. Then you see in Fiddlers log, that the first request (which is to api-proxy.cypress.io) is not visible in Fiddler (because it does not use the proxy at all) and then the second request (to api.cypress.io) is visible in Fiddler.

Roemer commented 9 months ago

We still need to use a workaround to get an immediate (fail) response for the first request:

echo "127.0.0.1    api-proxy.cypress.io" >> /etc/hosts

It works but having a correct solution would still be the preferred way.

jennifer-shehane commented 9 months ago

@Roemer Can you provide a repo that would reproduce the issue? For us to run?

Roemer commented 9 months ago

A repo would not be enough, you need a specific network setup to reproduce it. Basically, if you have a setup that blocks any internet access but allow connecting via a proxy, you would see that the first request to api-proxy.cypress.io is blocked and never reaches the proxy and then the second request to api.cypress.io would come thru the proxy and work.

Roemer commented 3 months ago

This issue is still pending and the corresponding PR was closed. It is almost impossible to create a sample repo / test for the issue as this needs a specific networking setup (which is often used by corporates). If a dev would look at the (now closed PR), it is fairly obvious that is it currently broken.