[BUG] route.continue: Protocol error (Fetch.continueRequest): Invalid InterceptionId.

[MattIPv4]

System info

• Playwright Version: v1.41.1
• Operating System: Ubuntu 20
• Browser: Chrome
• Other info: Using mcr.microsoft.com/playwright:v1.41.1-focal

Source code

await page.route('**/*', route => {
    const url = new URL(route.request().url());
    return domainsToBlock.has(url.hostname)
      ? route.abort()
      : route.continue()
//        .catch(e => {
//          console.error('Error while continuing route', url, e);
//        });
  });

Steps

Unfortunately, I don't have a great reproduction here -- we run this blocking interception all our tests. We're seeing enough failures as below though that it is pretty consistently resulting in our test suite failing.

Expected

Historically have never run into issues with this blocking, it aborts requests for domains we've blocked and otherwise just passes all other requests through without issue.

Actual

However, since updating to 1.41.1 (from 1.40.1) we're seeing rather random route.continue: Protocol error (Fetch.continueRequest): Invalid InterceptionId. being thrown for what appear to be legitimate requests that shouldn't be failing.

[yury-s]

There were some changes related to routing logic in 1.41 which likely cause the issue. Would be very helpful if you could provide a repro. Are you reusing the page between tests or could it be that another navigation starts while previous route handler is not yet done? You don't await for page.about/continue so they may well keep running when another navigation already invalidates them. You can try calling unrouteAll('wait') before proceeding to the navigation, to ensure there are no pending routes, it's hard to tell more precisely without seeing the code.

[MattIPv4]

Would be very helpful if you could provide a repro.

I'm not sure there is a particularly reliable repro, we've been seeing this failure randomly pop up in tests across our suite since the update.

A very simple test that I've seen this fail on in our CI repeatedly is:

import { test } from '@playwright/test';

const domainsToBlock = new Set(['tracking.digitalocean.com']);

test.beforeEach(async ({ page }) => {
  await page.route('**/*', route => {
    const url = new URL(route.request().url());
    return domainsToBlock.has(url.hostname)
      ? route.abort()
      : route.continue()
        .catch(e => {
          console.error('Error while continuing route', url, e);
        });
  });
});

test.describe('Help', () => {
  test('help should redirect to product docs', async ({ page }) => {
    await Promise.all([
      page.waitForURL('https://docs.digitalocean.com/support/', { waitUntil: 'commit' }),
      page.goto('https://www.digitalocean.com/help, { waitUntil: 'commit' }),
    ]);
  });
});

Are you reusing the page between tests or could it be that another navigation starts while previous route handler is not yet done?

We don't reuse the page, we do a beforeEach which registers this blocking logic, and then navigates to the relevant page for the test. Some of the tests do result in a redirect during the test, though where I've seen failures on those the requests throwing the error are from the final page, not the initial page.

You don't await for page.about/continue so they may well keep running when another navigation already invalidates them.

We're returning the abort/continue promise, which is the same as making the method async and awaiting them.

You can try calling unrouteAll('wait') before proceeding to the navigation, to ensure there are no pending routes, it's hard to tell more precisely without seeing the code.

I'm not sure I follow what this call would do, nor where it would go in the logic?

[yury-s]

A very simple test that I've seen this fail on in our CI repeatedly is:

I tried that, but the page doesn't seem to send any requests to tracking.digitalocean.com. I tried adding 'use.typekit.net' to the list of blocked domains, but to no avail.

We're returning the abort/continue promise, which is the same as making the method async and awaiting them.

What I meant is that the routing happens asynchronously and may still have in flight requests after you have finished the test.

I'm not sure I follow what this call would do, nor where it would go in the logic?

The easiest would be to try and put it into afterEach:

test.afterEach(async ({ page }) => {
  await page.unrouteAll({ behavior: 'ignoreErrors' });
});

[MattIPv4]

I tried that, but the page doesn't seem to send any requests to tracking.digitalocean.com. I tried adding 'use.typekit.net' to the list of blocked domains, but to no avail.

Yeah, I don't think that test would have anything that'd get aborted by the blocking logic (we run the logic on all our tests to be safe), but we still see the random continue call failures on that test (among others) sometimes.

What I meant is that the routing happens asynchronously and may still have in flight requests after you have finished the test.

The easiest would be to try and put it into afterEach:

test.afterEach(async ({ page }) => {
  await page.unrouteAll({ behavior: 'ignoreErrors' });
});

Ah, I see. I added this to every test file alongside the beforeEach with the blocking snippet (It would be nice to have #9468 so we don't need to do this in every file along with our blocking). However, no dice, still seeing the random errors thrown from the route.continue calls.