Request interception after woker start

[hpohlmeyer]

Hey,
I am working on a project where we are doing request interception.
In production everything works fine, but our tests are flaky because of the interplay with msw.

The first request will be intercepted, but every subsequent request will ignore the interceptor.
I think what is happening is the following:

1. msw mocks fetch using @mswjs/interceptors while starting the worker
2. Our request initialization also mocks fetch, so this is added on top of the fetch mocked by the worker
3. msw restores the original fetch, or mocks fetch again after every request, which removes our interceptor as well

If we change the order and do our interceptor initialization first, everything works fine, which supports that theory.

Can anyone confirm, that my assumptions are correct? And can I work around that somehow? I have tried to stop the worker before our interceptor initialization and restart it afterwards, but that did not work.

---

I have created a stackblitz repro of the problem:
https://stackblitz.com/edit/node-zczqnw?devtoolsheight=33&file=src/main.ts

You can run it with npm run dev and see the console output in your devtools.

[hpohlmeyer]

We have found the culprint for the problem. This is fixed if we set waitUntilReady to false. Because that actually mocks fetch.
I don’t see a way around that while keeping waitUntilReady, but if you have any ideas it would be greatly appreciated.

[kettanaito]

Note that waitUntilReady ensures that no requests happen until the worker has activated in order to handle them. Disabling that option subjects your app to race condition between requests and the worker activation.

I think the cause for the issue is that you have your own fetch stub. MSW won't play nicely if request modules are mocked multiple times by other tools.

Can you share more context on why do you need a custom fetch mock? Can your goal be achieved by MSW entirely?

[hpohlmeyer]

Hey, thanks for your feedback and my late reply!

You are right, our fetch stub gets applied after msw stubbed fetch. When msw restores the original fetch it also throws away our fetch stub. We are awaiting worker.start before we do anything in our tests, to avoid the race conditions you have mentioned. That works while we can avoid the fetch stub from msw by disabling waitUntilReady.

The context here is, that we are trying to intercept all fetch requests and block them depending on some criteria.
Our case for msw is a bit odd. In our tests we want to replicate third party scripts, that execute arbitrary JS on our site. E.g.: Our site injects a script from a third-party domain, that triggers a fetch call to yet another domain. Instead of spinning up multiple servers on different ports we are using msw to return the JS script from one domain and to reply to the fetch request from the other one.