grafana/k6 · error

run if waiting for debugger to attach: %w

Error message

run if waiting for debugger to attach: %w

What it means

During FrameSession construction (frame_session.go:129), k6 sends the CDP command Runtime.runIfWaitingForDebugger immediately after attaching to a target. If the command fails, the new frame session is abandoned with this wrapped error. Failure almost never means a debugger setting problem — it means the CDP session or target is already unusable (browser crashed, was killed, or the connection dropped).

Source

Thrown at internal/js/modules/k6/browser/common/frame_session.go:129

		teardownCtx:          teardownCtx,
		session:              s,
		page:                 p,
		parent:               parent,
		manager:              p.frameManager,
		targetID:             tid,
		contextIDToContextMu: sync.Mutex{},
		contextIDToContext:   make(map[cdpruntime.ExecutionContextID]*ExecutionContext),
		isolatedWorlds:       make(map[string]bool),
		eventCh:              make(chan Event),
		childSessions:        make(map[cdp.FrameID]*FrameSession),
		vu:                   k6ext.GetVU(ctx),
		k6Metrics:            k6Metrics,
		logger:               l,
		hasUIWindow:          hasUIWindow,
	}

	if err := cdpruntime.RunIfWaitingForDebugger().Do(cdp.WithExecutor(fs.ctx, fs.session)); err != nil {
		return nil, fmt.Errorf("run if waiting for debugger to attach: %w", err)
	}

	var parentNM *NetworkManager
	if fs.parent != nil {
		parentNM = fs.parent.networkManager
	}
	fs.networkManager, err = NewNetworkManager(ctx, k6Metrics, s, fs.manager, parentNM, fs.manager.page)
	if err != nil {
		l.Debugf("NewFrameSession:NewNetworkManager", "sid:%v tid:%v err:%v",
			s.ID(), tid, err)
		return nil, err
	}

	// When a frame creates a new FrameSession without UI (e.g. some iframes) we cannot
	// retrieve the windowID. Doing so would lead to an error from chromium. For now all
	// iframes that are attached are setup with hasUIWindow as false which seems to work
	// as expected for iframes with and without UI elements.
	if fs.hasUIWindow {

View on GitHub (pinned to 93accf6570)

Solutions

1. Check whether chromium died: look for OOM kills (dmesg | grep -i oom), raise container memory limits or lower VU/page counts
2. Verify the browser endpoint and settings (K6_BROWSER_WS_URL, K6_BROWSER_HEADLESS); reproduce with a local bundled chromium to rule out the remote
3. Upgrade k6 (and the chromium it drives) so CDP domains match; rerun — transient crashes at attach are common under load

try {
  const page = browser.newPage();
} catch (e) {
  if (/run if waiting for debugger/i.test(String(e))) {
    // chromium died at attach — recreate context/page once after a short pause
  }
}

When it happens

Trigger: Opening a page/new target at the exact moment chromium dies (OOM kill, crash), a remote browser (K6_BROWSER_WS_URL) that closes the session mid-attach, or a CDP endpoint/proxy with protocol version incompatibilities.

Common situations: Headless chromium killed by the OOM killer in memory-capped CI containers, k6 pointing at a wrong or flaky remote CDP endpoint, or browsers older/newer than the k6 build expects.

Related errors

• getting browser window ID: %w
• internal error while enabling %T: %w
• enabling page domain: %w
• evaluating pointer action: %w
• mouse down: %w

AI-assisted analysis of grafana/k6@93accf6570 (2026-08-15). Data as JSON: /api/errors/2dc3fe45f8789b2f. Report an issue: GitHub.