What causes "fail to continue request (id: %s): %w" in grafana/k6?

Call continue() exactly once, synchronously, at the top of the handler

fail to continue request (id: %s): %w

Error message

fail to continue request (id: %s): %w

What it means

The CDP command Fetch.continueRequest failed while resuming an intercepted request. The known-benign 'Invalid InterceptionId' case is already filtered out and logged as debug; this error means something else went wrong — the interception was never enabled for this session, the request is stale, or the session is gone.

Source

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

		// Avoid logging as error when context is canceled.
		// Most probably this happens when trying to fail a site's background request
		// while the iteration is ending and therefore the browser context is being closed.
		if errors.Is(err, context.Canceled) {
			m.logger.Debug("NetworkManager:ContinueRequest", "context canceled continuing request")
			return nil
		}

		// This error message is an internal issue, rather than something that the user can
		// action on. It's also usually ok to ignore since it means that the page has navigated
		// away or something has occurred which means that the request is no longer needed and
		// isn't being tracked by chromium.
		if strings.Contains(err.Error(), "Invalid InterceptionId") {
			m.logger.Debugf("NetworkManager:ContinueRequest", "invalid interception ID (%s) continuing request: %s",
				requestID, err)
			return nil
		}

		return fmt.Errorf("fail to continue request (id: %s): %w", requestID, err)
	}

	return nil
}

func (m *NetworkManager) FulfillRequest(request *Request, opts FulfillOptions) error {
	responseCode := int64(http.StatusOK)
	if opts.Status != 0 {
		responseCode = opts.Status
	}

	action := fetch.FulfillRequest(request.interceptionID, responseCode)

	if opts.ContentType != "" {
		opts.Headers = append(opts.Headers, HTTPHeader{
			Name:  "Content-Type",
			Value: opts.ContentType,
		})

View on GitHub (pinned to 93accf6570)

Solutions

Call continue() exactly once, synchronously, at the top of the handler
Await route registration before goto() and unroute() before close() so Fetch is enabled/disabled in order
If the handler must do async work first, re-fetch a fresh route or accept the failure — guard the call and log it rather than failing the iteration
Enable DEBUG=k6-browser to see whether the underlying error is 'Fetch.enable isn't enabled' (ordering bug) vs session-closed (lifecycle race)

Example fix

// before
page.route('**/api/**', async r => {
  const data = await otherWork();
  await r.continue(); // interception may be stale
});

// after
page.route('**/api/**', r => r.continue()); // continue immediately

Defensive patterns

Strategy: try-catch

Try / catch

try {
  await route.continue();
} catch (e) {
  const s = String(e);
  if (/fail to continue request/.test(s)) return; // request already gone
  throw e;
}

Prevention

Continue exactly once per intercepted request, ideally synchronously
Await route registration before goto() and unroute() before close()
Keep handler logic synchronous when the decision needs no I/O; defer only when you accept staleness

When it happens

Trigger: route.continue() after the page navigated and the interception was torn down; calling continue() twice on the same route handler; calling continue() after unroute() disabled Fetch on that target; issuing it after context close but before context cancellation propagates.

Common situations: Async route handlers that await slow work then continue(); handlers racing navigation/redirect; SPAs where chromium already dropped the request. Frequently appears together with rapid goto() calls in a loop.

Related errors

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