fix(browser): raise protocolTimeout to 10min for heavy pages#2010
Open
triuzzi wants to merge 1 commit into
Open
fix(browser): raise protocolTimeout to 10min for heavy pages#2010triuzzi wants to merge 1 commit into
triuzzi wants to merge 1 commit into
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Author
|
@googlebot I signed it! |
a52a18a to
38a09eb
Compare
Heavy pages (e.g. dev bundles >100MB) cannot ack `Network.enable` and other auto-attached CDP domain calls within puppeteer's default 180s. Once the timeout fires, puppeteer marks the connection dead and every subsequent call throws `Network.enable timed out` — only daemon restart recovers. Set `protocolTimeout: 600000` on both `puppeteer.connect()` and `puppeteer.launch()`. Env-overridable via `CHROME_DEVTOOLS_PROTOCOL_TIMEOUT_MS` for power users. Hit in real workloads against a Brightcove Studio dev bundle (~160MB JS) where the default timeout fired before `list_pages` could complete, leaving the daemon permanently wedged.
38a09eb to
5348bf7
Compare
OrKoN
reviewed
May 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Heavy pages (e.g. dev bundles >100MB) cannot ack
Network.enableand other auto-attached CDP domain calls within puppeteer's default 180s. Once the timeout fires, puppeteer marks the connection dead and every subsequent call throwsNetwork.enable timed out— only daemon restart recovers.Set
protocolTimeout: 600000on bothpuppeteer.connect()andpuppeteer.launch(). Env-overridable viaCHROME_DEVTOOLS_PROTOCOL_TIMEOUT_MSfor power users.Repro
Hit during real-world testing against a Brightcove Studio dev bundle (~160MB JS):
After the failure, every subsequent call returned the same timeout. The daemon process was alive (
process.kill(pid, 0)returned true), so client retries reused the wedged connection until manually killed.Why 10min
Puppeteer's 180s default is calibrated for small pages and CI runners. For real-world dev work (HMR-enabled webpack bundles, large React apps), 10min is comfortable headroom while still bounded enough to surface genuine deadlocks. Env-overridable so power users with even-larger workloads aren't blocked.
Testing
npm run buildcleanNetwork.enable timed outno longer surfacesNote
A previous PR (#2009) was opened from a downstream fork and accidentally pulled in 9 fork-specific commits — closed and re-submitted as this clean single-commit PR branched from
main.🤖 Generated with Claude Code