Allow mocks to be scoped to browser tab

[thepassle]

We use @web/test-runner, which runs each test file in a real browser (via puppeteer/playwright), in its own separate browser tab for concurrency and test isolation.

Given:

foo.test.js
bar.test.js

@web/test-runner would spawn a browser with 2 browser tabs, one for foo.test.js and one for bar.test.js.

Considering that there is only one service worker for an origin (in the case of test runs, localhost), this means that potentially race conditions can exist, where foo.test.js accidentally overrides mocks in bar.test.js. We've introduced MSW via @web/mocks at ING, and interestingly I havent ran into this issue yet. There has been one instance of a reported issue where I suspected this might be happening, but then it magically resolved itself and then became unreproducible.

In any case, I think we can make MSW more robust in cases where MSW is used in multiple tabs at a time (which I think is also the direction Vitest browser is going). I think this change can be opt-in, and configurable via the worker.start configuration. Some initial thoughts on what this could look like is:

const worker = setupWorker();
worker.start({
  scopeMocksPerTab: true,
});

We can think of a better name than scopeMocksPerTab, ofcourse.

Given that we already have the clientId as a unique identifier for each browser tab in the service worker, we should be able to keep some kind of map to identify which browser tab has registered which mocks, and only respond with mocks to a request if the current request comes from the correspondig browser tab.

If everything about this sounds agreeable, I'd be happy to try to take a stab at implementing this and creating a PR.

[kettanaito]

Hey, @thepassle. Thanks for proposing this. Let's discuss it a bit before we come up with the best way to support this.

So, here I was writing a really detailed proposal when I noticed that we kind of already guard against this very concurrence issue. Take a look at this:

msw/src/mockServiceWorker.js

Lines 156 to 177 in f5f31fa

	async function resolveMainClient(event) {
	const client = await self.clients.get(event.clientId)
	if (client?.frameType === 'top-level') {
	return client
	}
	const allClients = await self.clients.matchAll({
	type: 'window',
	})
	return allClients
	.filter((client) => {
	// Get only those clients that are currently visible.
	return client.visibilityState === 'visible'
	})
	.find((client) => {
	// Find the client ID that's recorded in the
	// set of clients that have registered the worker.
	return activeClientIds.has(client.id)
	})
	}

The way MSW worker functions right now, it will only signal the REQUEST message event to the client that issued the request. This should guarantee that if the foo client makes a request, the bar client won't even get notified about it.

One case where I thought issues may arise is if you add runtime handlers via worker.use() but that's not relevant, really. worker.use() will modify the worker object that is unique to each runtime/client. The handlers you append in one tab won't exist in the other tab. Granted, we don't currently have tests to confirm this, but the behavior is similar to that of .stop(), which we do test in multi-tab scenarios:

msw/test/browser/msw-api/setup-worker/stop.test.ts

Line 54 in f5f31fa

test('keeps the mocking enabled in one tab when stopping the worker in another tab', async ({

Perhaps starting from an integration test for this two-client scenario is the right approach here.

[thepassle]

I was actually trying to reproduce the behavior the other day locally, but I wasnt able to reproduce, and combined with the code you linked above, and the fact that I havent ran into this issue on some of the projects at work, that makes me pretty confident that the requests indeed already are scoped per client

There has been one instance of a reported issue where I suspected this might be happening, but then it magically resolved itself and then became unreproducible.

This is turning out to be something different, but not related to MSW

[kettanaito]

Well, I'm glad we've discovered that. All merits go to the Service Worker API (and MessageChannel) for making across-client communication more effort 😄 So we message back only to the request issuer.