mirror of
https://github.com/browser-use/browser-use
synced 2026-04-22 17:45:09 +02:00
9a09c4d7dc
cdp_use.CDPClient.send_raw awaits a future that only resolves when the browser sends a response with a matching message id. There is no timeout on that await. Against the cloud browser service, the failure mode we observed is: WebSocket stays alive at the TCP/keepalive layer (proxy keeps pong-ing our pings), but the browser upstream is dead / unhealthy and never sends any CDP response. send_raw's future never resolves, and every higher-level timeout in browser-use (session.start's 15s connect guard, agent.step_timeout, tools.act's action timeout) relies on eventually getting a response — so they all wait forever too. Evidence from a 170k-task collector run: 1,090 empty-history traces, 100% hit the 240s outer watchdog, median duration 582s, max 2214s, with cloud HTTP layer clean throughout (all 200/201). One sample showed /json/version returning 200 OK and then 5 minutes of total silence on the WebSocket before forced stop — classic silent-hang. Fix: add TimeoutWrappedCDPClient, a thin subclass of cdp_use.CDPClient that wraps send_raw in asyncio.wait_for(timeout=cdp_request_timeout_s). Any CDP method that doesn't respond within the cap raises plain TimeoutError, which propagates through existing `except TimeoutError` handlers in session.py / tools/service.py. Uses the same defensive env parse pattern as BROWSER_USE_ACTION_TIMEOUT_S — rejects empty / non-numeric / nan / inf / non-positive values with a warning fallback. Default is 60s: generous for slow operations like Page.captureScreenshot or Page.printToPDF on heavy pages, but well below the 180s step timeout and any typical outer watchdog. Override via BROWSER_USE_CDP_TIMEOUT_S. Wired into both CDPClient construction sites in session.py (initial connect + reconnect path). All 17 existing real-browser tests (test_action_blank_page, test_multi_act_guards) still pass.
Codebase Structure
The code structure inspired by https://github.com/Netflix/dispatch.
Very good structure on how to make a scalable codebase is also in this repo.
Just a brief document about how we should structure our backend codebase.
Code Structure
src/
/<service name>/
models.py
services.py
prompts.py
views.py
utils.py
routers.py
/_<subservice name>/
Service.py
Always a single file, except if it becomes too long - more than ~500 lines, split it into _subservices
Views.py
Always split the views into two parts
# All
...
# Requests
...
# Responses
...
If too long → split into multiple files
Prompts.py
Single file; if too long → split into multiple files (one prompt per file or so)
Routers.py
Never split into more than one file