Can MSW intercept calls being made by another Service Worker?

[mickeypuri]

In our application, for efficiency, all network calls are made via a Service Worker. So the application sends a message to the Service Worker which makes the network call and returns the response to the application.

Given this scenario, is it still possible to use the MSW library and how, or would we be better to roll our own solution for this use case?

[kettanaito]

Hi, @mickeypuri.

I don't believe that's possible. The fetch() you perform in a Service Worker context is a different function that window.fetch() on the page. That prevents the worker from an infinite loop where it would want to perform an intercepted request as-is:

// some-worker.js
self.addEventListener('fetch', (event) => {
  event.respondWith(
    // If this fetch triggers the "fetch" event in the worker,
    // it will cause an infinite loop. 
    fetch(event.request)
  )
})

You can, however, combine multiple Service Workers via imporScripts(), which will make them share their scope.

// some-worker.js
importScripts('/mockServiceWorker.js')

self.addEventListener('fetch', (event) => {
  event.respondWith(
    // If this fetch triggers the "fetch" event in the worker,
    // it will cause an infinite loop. 
    fetch(event.request)
  )
})

By sharing the scope, one service worker can spy on the fetch calls of another service worker (basically, on the fetch() function of their shared global scope) and handle them.

MSW doesn't do that because it's an extremely specific behavior. It sounds like the setup you have to establish on your end. If you are okay with that, this is what I suggest:

// your-worker.js
// Import MSW first so it adds the "fetch" listener first.
importScripts('/mockServiceWorker.js')

self.addEventListener('message', (event) => {
  // In the handler for the client messages that trigger
  // requests, forward those requests onto the global scope.
  if (event.data.type === 'REQUEST') {
    const request = new Request(event.data.requestInfo)

    // This will trigger all "fetch" event listeners
    // in your Service Worker and in MSW's service worker as well.
    self.dispatchEvent(new FetchEvent('fetch', {
      request,
    }))
  }
})

This should be a good point to get you started.

[mickeypuri]

Hi, @kettanaito

I had felt it would be an issue, and hence wanted to check. Thank you for a detailed answer and suggestion.

In our use case, there are two scenarios:

MSW has a mocked route
MSW Worker Responds with mocked response,
Our other Worker does not respond OR our other worker gets its response from the MSW Worker

MSW has not got a mocked route
MSW Worker does not pass the request on to the API
Our other Worker responds as normal to the Request.

So they cannot be in parallel, and in effect, the MSW Worker is in between our other worker and the network. Where MSW can handle it it returns the request to our worker, where MSW hasn't a route, then it fetches it and then returns the response back to our worker.

Since they are both workers, to get like a hierarchy and have them in series may be difficult, and so perhaps I need to find some other solution, but appreciate your thoughts if you can see some other approach here, thank you.

[kettanaito]

You can still guarantee the execution order. Event listeners are sensitive to the declaration order. If you add MSW first via importScripts(), it will attach its request listeners before your worker. Event listeners are also called synchronously (the fetch even is forced to be synchronous) so if MSW handles an outgoing request, the fetch event of your custom worker will never be called.

I don't know if this is what you want but you can certainly guarantee the order here.

[mickeypuri]

Hi @kettanaito

That is great to hear that they are called synchronously, and that we can guarantee the order. So MSW would handle calls first, before our custom service worker.

If MSW handles the outgoing request and returns a mocked request, then what stops the fetch event of our other service worker, which is waiting in the queue to be handled from being invoked? Do we need to do anything special to stop the event from being propogated further to other listeners?

My understanding of how MSW works is that if MSW does not find a mocked response, then it passes the request onto the network. So in this case might we still end up with MSW passing the request to the network, and our custom worker still getting the request as its not been handled by MSW, and we end up having two network requests being made, one from MSW and the other from our custom worker. Could this situation arise?

[kettanaito]

Yeah, a good point. The only way to handle a request in any way is to call event.respondWith() in the fetch event. MSW does that and wraps the rest of the request handling logic within that function's callback. This means that in either case (mocked/bypassed response), the worker will consider the fetch event handled. My bad, I haven't realized that.

I believe if the fetch is handled, no further fetch listeners will be called (cannot handle the same fetch event twice, it's forbidden by the spec). This means that your worker's fetch listeners will never be called at all if you import MSW's worker before it.

That's a pickle. I don't have what to suggest to you right now.

[mickeypuri]

For a moment I thought maybe we can get something, but now I see it is not going to be possible. Thank you for helping to think this thru.

I guess now to do this, we will have to do something custom in our service worker. In effect a bit like MSW itself, we either pull it from our preset or mocked values and if not there, then we pass on the call to the network and return a fetched response.

Many thanks for helping think thru this situation.