grafana/k6 · error

initializing networking %T: %w

Error message

initializing networking %T: %w

What it means

Thrown from NetworkManager.initDomains when a CDP domain-enabling command fails during page setup: network.Enable(), or — when request interception is on — network.SetCacheDisabled(true) plus fetch.Enable(). The %T names the exact action that failed. It almost always means the DevTools session/target was unusable: browser crashed, page closed mid-setup, or a protocol/version mismatch.

Source

Thrown at internal/js/modules/k6/browser/common/network_manager.go:376

	m.eventInterceptor.onResponse(resp)
	m.eventInterceptor.onRequestFinished(req)
	m.emit(cdproto.EventNetworkResponseReceived, resp)
	m.emit(cdproto.EventNetworkLoadingFinished, req)
}

func (m *NetworkManager) initDomains() error {
	actions := []Action{network.Enable()}

	// Only enable the Fetch domain if necessary, as it has a performance overhead.
	if m.userReqInterceptionEnabled {
		actions = append(actions,
			network.SetCacheDisabled(true),
			fetch.Enable().WithPatterns([]*fetch.RequestPattern{{URLPattern: "*"}}))
	}
	for _, action := range actions {
		if err := action.Do(cdp.WithExecutor(m.ctx, m.session)); err != nil {
			return fmt.Errorf("initializing networking %T: %w", action, err)
		}
	}

	return nil
}

func (m *NetworkManager) initEvents() {
	chHandler := make(chan Event)
	m.session.on(m.ctx, []string{
		cdproto.EventNetworkLoadingFailed,
		cdproto.EventNetworkLoadingFinished,
		cdproto.EventNetworkRequestWillBeSent,
		cdproto.EventNetworkRequestWillBeSentExtraInfo,
		cdproto.EventNetworkRequestServedFromCache,
		cdproto.EventNetworkResponseReceived,
		cdproto.EventNetworkResponseReceivedExtraInfo,
		cdproto.EventFetchRequestPaused,
		cdproto.EventFetchAuthRequired,

View on GitHub (pinned to 93accf6570)

Solutions

  1. Reproduce with a single VU to rule out resource exhaustion; check Chromium process/container logs and memory limits
  2. If using an external browser, remove K6_BROWSER_EXECUTABLE_PATH to test with the bundled Chromium, or update to a compatible version
  3. Reduce browser-level parallelism (scenarios, VUs, pages per iteration)
  4. Upgrade k6 so the vendored chromedp/cdproto matches current Chromium releases

Example fix

# before: pinned old external chrome, many pages
K6_BROWSER_EXECUTABLE_PATH=/usr/bin/chrome-old k6 run -u 50 browser.js

# after: bundled chromium, single-VU reproduction to isolate
k6 run -u 1 browser.js
Defensive patterns

Strategy: retry

Validate before calling

// smoke-test browser health before the workload
import browser from 'k6/browser';

export default async function () {
  const ctx = await browser.newContext();
  const p = await ctx.newPage(); // fails here if domains can't initialize
  await p.close();
  await ctx.close();
}

Try / catch

try {
  const page = await ctx.newPage();
} catch (e) {
  if (/initializing networking/i.test(e.message)) {
    // browser/target unusable: recreate context once, then abort with diagnostics
    throw new Error(`browser networking init failed: ${e.message}`);
  }
  throw e;
}

Prevention

When it happens

Trigger: Opening a new page while the browser process has crashed or is OOM; the target is destroyed during context creation; enabling the Fetch domain fails because interception (K6_BROWSER_... routing/hosts features) requires protocol support the connected Chromium does not implement; version mismatch when pointing K6_BROWSER_EXECUTABLE_PATH at an incompatible Chrome build.

Common situations: High VU counts spawning many pages until Chromium dies; constrained container memory; using an external/oversized Chrome with a cdproto version skew; CI runners where the browser binary is missing dependencies and dies instantly.

Related errors


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