Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix browser: listPagesViaPlaywright lacks timeout protection, causing all HTTP requests to 500 when CDP connection hangs [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#58968•Fetched 2026-04-08 02:30:33
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
KeaneYanKeaneYan
Participants
KeaneYanKeaneYan
Timeline (top)
cross-referenced ×1renamed ×1

Error Message

  1. Add meaningful error logging in catch blocks for easier debugging (currently the catch block is empty, making diagnosis nearly impossible)

Root Cause

listPagesViaPlaywright (in gateway-cli source) has no timeout set. When the CDP connection stalls, this call blocks indefinitely. Since it appears to be on the synchronous path of HTTP request handling, it blocks the entire service.

Fix Action

Fixed

PR fix notes

PR #59043: fix(browser): add timeout protection to listPagesViaPlaywright

Description (problem / solution / changelog)

Fixes #58968

Root cause

listPagesViaPlaywright calls pageTargetId() (which opens a CDP session and sends Target.getTargetInfo) and page.title() inside a loop. Neither has a timeout. When a browser profile's CDP endpoint is connected but not responding to protocol commands — hung tab, stalled renderer — these calls block indefinitely. The suspension propagates up to the HTTP handler for tab listing, eventually causing an HTTP 500 after the server's own timeout fires.

connectBrowser already has timeout protection (5–9 s per attempt, 3 retries). The post-connection enumeration did not.

Fix

Extract the enumeration loop into a private listPagesCore helper, then wrap the public listPagesViaPlaywright in a 15-second Promise.race timeout — the same pattern used by the CDP socket helper already in this file. Add a focused regression test: a browser mock whose CDP session never resolves, fake-timer advance to 15 s, assert rejection with a clear message.

Changed files

  • extensions/browser/src/browser/pw-session.ts — timeout wrapper + extracted helper
  • extensions/browser/src/browser/pw-session.connections.test.ts — regression test

Changed files

  • extensions/browser/src/browser/pw-session.connections.test.ts (modified, +43/-0)
  • extensions/browser/src/browser/pw-session.ts (modified, +23/-1)
RAW_BUFFERClick to expand / collapse

Bug Description

When connecting to a remote browser via CDP (e.g., Windows Chrome at 172.25.80.1:9223), if the CDP connection becomes unstable or times out, listPagesViaPlaywright hangs indefinitely, causing all gateway HTTP requests to return 500.

Reproduction Steps

  1. Configure gateway.bind and browser to use a remote CDP port
  2. While the CDP connection is unstable (e.g., during frequent gateway restarts), access the Control Center or make API requests
  3. All HTTP requests return 500

Root Cause

listPagesViaPlaywright (in gateway-cli source) has no timeout set. When the CDP connection stalls, this call blocks indefinitely. Since it appears to be on the synchronous path of HTTP request handling, it blocks the entire service.

Suggested Fixes

  1. Add a reasonable timeout to listPagesViaPlaywright (e.g., 10-30 seconds)
  2. Gracefully degrade on timeout — return an empty list or cached result instead of blocking the entire request chain
  3. Add meaningful error logging in catch blocks for easier debugging (currently the catch block is empty, making diagnosis nearly impossible)

Environment

  • OpenClaw: 2026.3.31 (213a704)
  • OS: WSL2 (Ubuntu) on Windows 11
  • Browser: Windows Chrome via CDP (172.25.80.1:9223)
  • Node: v22.22.0

extent analysis

TL;DR

Add a reasonable timeout to listPagesViaPlaywright to prevent indefinite hanging when the CDP connection is unstable.

Guidance

  • Set a timeout in the range of 10-30 seconds for listPagesViaPlaywright to allow the service to recover from CDP connection stalls.
  • Implement a fallback strategy, such as returning an empty list or a cached result, when the timeout is reached to prevent blocking the entire request chain.
  • Enhance error logging in catch blocks to facilitate easier diagnosis of issues related to CDP connection instability.
  • Consider reviewing the CDP connection configuration and stability to minimize the occurrence of timeouts and stalls.

Example

// Example of adding a timeout to listPagesViaPlaywright
const timeout = 20000; // 20 seconds
const pages = await Promise.race([
  listPagesViaPlaywright(),
  new Promise((_, reject) => setTimeout(() => reject(new Error('Timeout')), timeout))
]);

Notes

The suggested fixes assume that the CDP connection instability is unavoidable. However, investigating and addressing the root cause of the CDP connection issues may provide a more robust solution.

Recommendation

Apply a workaround by adding a timeout to listPagesViaPlaywright, as this provides a immediate solution to prevent indefinite hanging and allows for further investigation into the CDP connection stability.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#model save/load#optimization#mixed precision#training loop

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix browser: listPagesViaPlaywright lacks timeout protection, causing all HTTP requests to 500 when CDP connection hangs [1 pull requests, 1 participants]