Skip to content

errors: classify CDP debugger-detach as transient (retry-able)#1182

Open
gucasbrg wants to merge 1 commit intojackwener:mainfrom
gucasbrg:add-detach-retry-patterns
Open

errors: classify CDP debugger-detach as transient (retry-able)#1182
gucasbrg wants to merge 1 commit intojackwener:mainfrom
gucasbrg:add-detach-retry-patterns

Conversation

@gucasbrg
Copy link
Copy Markdown
Contributor

Problem

classifyBrowserError does not list the Detached while handling command pattern (or the related No tab with id / Debugger is not attached to the tab), so when the daemon emits one of them under concurrent load, the CLI surfaces it to callers as a hard failure instead of going through the existing retry loop in sendCommandRaw.

The e2e test harness tests/e2e/browser-public.test.ts already treats these three patterns as transient and retries:

function isTransientBrowserDetach(result: CliResult): boolean {
  const text = `${result.stderr}\n${result.stdout}`;
  return /Detached while handling command|No tab with id|Debugger is not attached to the tab/i.test(text);
}

So the "transient" judgement is already established — it just was not reflected in the runtime classifier.

Real-world impact

A news collector pipeline that calls web read --url … for ~20 BBC RSS items in parallel (workers=3) hit ~30-50 % spurious 500 failures even though re-running the failed items individually succeeds instantly. With this patch, daemon-client retries them automatically and end-to-end success is ~100 %.

Change

  • Add three patterns to EXTENSION_TRANSIENT_PATTERNS in src/browser/errors.ts.
  • Add the same patterns to the existing positive case in src/browser/errors.test.ts. Vitest passes (7/7).

No behavioural change for callers that were already reaching the e2e helper; this just brings the runtime classifier into agreement with the e2e helper.

When a daemon command races with another concurrent command, the daemon
emits "Detached while handling command id=..." and aborts. The e2e test
harness already treats this (and the related "No tab with id" / "Debugger
is not attached to the tab") as transient and retries
(tests/e2e/browser-public.test.ts `isTransientBrowserDetach`).

But `classifyBrowserError` did not list these patterns, so at runtime the
CLI surfaced the error to the caller as a hard failure instead of going
through the existing daemon-client retry loop. Calling `web read` (or any
browser command) with parallelism >1 hit ~10-30% spurious failures even
though the next attempt would succeed instantly.

Add the three patterns and a regression test mirroring the e2e helper.
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.

1 participant