[Bug]: Time out when downloading browsers

[ArnaudBarre]

Version

1.50.1

Steps to reproduce

• Have a bad internet connection
• Run pnpm exec playwright install

Expected behavior

Browsers download slowly in one go

Actual behavior

Downloading Chromium Headless Shell 133.0.6943.16 (playwright build v1155) from https://cdn.playwright.dev/dbazure/download/playwright/builds/chromium/1155/chromium-headless-shell-mac-arm64.zip
77.9 MiB [======              ] 28% 75.7sError: Request to https://cdn.playwright.dev/dbazure/download/playwright/builds/chromium/1155/chromium-headless-shell-mac-arm64.zip timed out after 30000ms
    at ClientRequest.rejectOnTimeout (/Users/arnaud/git/vite-plugin-react-swc/node_modules/.pnpm/playwright-core@1.50.1/node_modules/playwright-core/lib/utils/network.js:76:15)
    at Object.onceWrapper (node:events:621:28)
    at ClientRequest.emit (node:events:507:28)
    at TLSSocket.emitRequestTimeout (node:_http_client:863:9)
    at Object.onceWrapper (node:events:621:28)
    at TLSSocket.emit (node:events:519:35)
    at Socket._onTimeout (node:net:609:8)
    at listOnTimeout (node:internal/timers:614:17)
    at process.processTimers (node:internal/timers:549:7)
Downloading Chromium Headless Shell 133.0.6943.16 (playwright build v1155) from https://playwright.download.prss.microsoft.com/dbazure/download/playwright/builds/chromium/1155/chromium-headless-shell-mac-arm64.zip
77.9 MiB [====================] 100% 0.0s
Chromium Headless Shell 133.0.6943.16 (playwright build v1155) downloaded to /Users/arnaud/Library/Caches/ms-playwright/chromium_headless_shell-1155

Additional context

The download actually went through the second try, but that's 30s waisted on each browser

Environment

MacOS 15, node v23.7.0

[mxschmitt]

This timeout usually only hits if there is a TCP timeout hitting. Do you by any chance e.g. have a high package loss?

You could try to increase it by setting the PLAYWRIGHT_DOWNLOAD_CONNECTION_TIMEOUT=90000 env.

[ArnaudBarre]

It did that for all three browsers, exactly the same behaviour: download for 30s, cancel, retry and download for ~90s (connection was around ~1MB/s). The fact that is succeeded the second time without issue shows that the initial timeout has not a lot of effect except making things longer.
This article on this matter is great: https://brr.fyi/posts/engineering-for-slow-internet

[mxschmitt]

We were discussing it with the team and not sure how much we can improve there. Afaik we only call socket.setTimeout which hits if there is inactivity on the TCP socket. 30s seems like a good default and as 90s doesn't work for you it seems like something is off with your internet connection it seems like.

I'll leave it open a bit if you have any other findings, feel free to post them here. If you believe its a Playwright bug / the timeout is thrown incorrectly, let us know / debug it further! So far this is not actionable for us, since there weren't other folks running into it / the code looks reasonable.

[ArnaudBarre]

There was activity, the percentage bar was going up almost every second. The current behaviour makes me think the timeout was on global request time and not inactivity, but maybe this is a bug in recent node and not playwright.

[zkeetonev]

I just upgraded past 1.50.0 and started getting the same issue. My internet connection is slow, yes, but there is constant activity during the download. Then it just quits midway through.

[stevenh]

Seeing the same thing here too

[mccataldo]

Arnaud Barré (@ArnaudBarre) why did you close this? Did you resolve it? If so, please share.

[ArnaudBarre]

I closed this because it finally worked and I didn't want to waste time on investigating if this is a bug in this project or a dependency or node.

[stevenh]

Definitely a bug, happens every time it starts a download from a clean cache, would you mind reopening please Arnaud Barré (@ArnaudBarre) ?

[yury-s]

Can you try setting longer timeout with PLAYWRIGHT_DOWNLOAD_CONNECTION_TIMEOUT to say 60000 and see if it helps?

[stevenh]

Yury Semikhatsky (@yury-s) could you clarify the intent of that setting as the name implies it's a timeout on the initial connection which is not what's happening, that is an active connection is aborted while actively downloading?

[yury-s]

We suspect that the idle timeout might be triggered after the connection has been established and download already started. We want to rule out the case that the socket is idling for 30+ s after the download has started already.

[stevenh]

You can rule that out, the progress bar was merrily ticking up every time it has timed out for me. What's interesting is that it only does it the first time, after it reconnects it doesn't do it.