fix: suppress CDP error -32000 to prevent session corruption

[FaisalFehad]

Problem

When using browser automation tools that depend on cdp-use, file uploads and page transitions consistently cause browser sessions to become unusable with the error:

RuntimeError: {"code": -32000, "message": "Browser window not found"}

This makes all subsequent commands (state, wait stable, screenshot, etc.) fail, rendering the browser session permanently broken.

Root Cause

The error occurs during a race condition in the CDP event handler:

1. _on_target_info_changed fires when a new target is discovered (e.g., file upload or page navigation creates a new page context)
2. _trigger_page_target_discovered calls Browser.getWindowForTarget for the new target
3. The target exists in CDP but doesn't yet have an associated window binding
4. CDP returns error -32000 ("Browser window not found")
5. The RuntimeError is raised and propagates through the event handler
6. The unhandled exception crashes the event handler and corrupts the session
7. All subsequent CDP calls fail because the session state is inconsistent

Fix

In CDPClient._handle_messages(), when a CDP response contains error -32000, return a default window result instead of raising RuntimeError. This allows the session to continue normally — the target will get its window binding shortly after.

Other CDP errors are still raised as RuntimeError as before.

Testing

Verified with browser-act:

• ✅ Open browser session
• ✅ Navigate to pages
• ✅ File uploads (previously crashed the session)
• ✅ Click buttons and interact with elements
• ✅ state command works after interactions
• ✅ wait stable command works after interactions
• ✅ Complete automation flow works end-to-end

Changes

• cdp_use/client.py: Added error suppression for CDP error code -32000 in _handle_messages(), returning a default window result {"windowId": 0, "bounds": {"left": 0, "top": 0, "width": 1920, "height": 1080, "windowState": "normal"}} instead of raising RuntimeError

[cubic-dev-ai]

1 issue found across 1 file

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[FaisalFehad]

@cubic-dev-ai Issue addressed in commit 1e7577e.

The -32000 suppression is now scoped to Browser.getWindowForTarget only.

Changes:

1. pending_requests now stores (future, method) tuples instead of bare futures
2. send_raw() stores the CDP method name alongside each future
3. _handle_messages() unpacks (future, request_method) and only suppresses -32000 when request_method == "Browser.getWindowForTarget"
4. Exception handlers updated to unpack (future, _) tuples

No other CDP methods will receive fabricated window-shaped results.

[cubic-dev-ai]

@cubic-dev-ai Issue addressed in commit 1e7577e.

The -32000 suppression is now scoped to Browser.getWindowForTarget only.

Changes:
...

@FaisalFehad Looks good — the scoping change you made in commit 1e7577e cleanly addresses the concern about blanket -32000 suppression.

A couple of observations on the implementation:

What works well:

• Storing (future, method) tuples instead of separate tracking dicts keeps it simple — one data structure, no sync issues.
• The guard condition is tight: both isinstance(error, dict) and error.get("code") == -32000 before checking the method name. That avoids any AttributeError if CDP ever returns a non-dict error shape.
• The info log on suppression is at logger.info which is appropriate — this is an unusual event worth knowing about in production logs.

One minor thing worth considering:

The default bounds you return (width: 1920, height: 1080) hardcode a specific viewport. If the caller actually uses those bounds (e.g., for positioning or sizing), you could get a brief visual glitch. A safer alternative might be raising the exception after a short retry, but that's a much bigger change and probably not worth it — in practice, these window-less targets get their binding immediately, so the fake result is consumed and discarded before anything sees it. Just worth being aware of if you ever see weird initial sizes in downstream code.

Otherwise, this is a solid fix for a nasty race condition. The method-scoped suppression keeps it surgical while the race window stays open.

_{Tip: get faster answers by chatting with cubic’s review copilot in the review UI}