Skip to content

fix(browser): raise protocolTimeout to 10min for heavy pages#2010

Open
triuzzi wants to merge 1 commit into
ChromeDevTools:mainfrom
triuzzi:feat/protocol-timeout-upstream
Open

fix(browser): raise protocolTimeout to 10min for heavy pages#2010
triuzzi wants to merge 1 commit into
ChromeDevTools:mainfrom
triuzzi:feat/protocol-timeout-upstream

Conversation

@triuzzi
Copy link
Copy Markdown

@triuzzi triuzzi commented May 7, 2026

Summary

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.

Repro

Hit during real-world testing against a Brightcove Studio dev bundle (~160MB JS):

$ chrome-devtools-mcp start --browserUrl http://127.0.0.1:9222
$ chrome-devtools-mcp list_pages
[{"type":"text","text":"Network.enable timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed."}]

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 build clean
  • Verify on a real heavy-page session that Network.enable timed out no longer surfaces

Note

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

@google-cla
Copy link
Copy Markdown

google-cla Bot commented May 7, 2026

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.

@triuzzi
Copy link
Copy Markdown
Author

triuzzi commented May 7, 2026

@googlebot I signed it!

@triuzzi triuzzi force-pushed the feat/protocol-timeout-upstream branch from a52a18a to 38a09eb Compare May 7, 2026 14:09
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.
@triuzzi triuzzi force-pushed the feat/protocol-timeout-upstream branch from 38a09eb to 5348bf7 Compare May 7, 2026 14:10
Copy link
Copy Markdown
Collaborator

@OrKoN OrKoN left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please provide a test site you see this with?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants