Is it possible for worker.stop() to return a promise?

[bertdeblock]

I think worker.stop() used to return a promise in older versions of MSW? This doesn't seem to be the case anymore.
Is it possible to bring back this functionality or is there a technical reason that prevents worker.stop() from returning a promise?
The reason I'm asking is because, we have a scenario where we call worker.stop() and immediately do a fetch call afterwards. Sometimes the call works as intended, but other times this leaves the fetch promise in an infinite pending state. The worker seems to intercept the fetch call, but is not able to send back the original response because it has also received the stop command (or something to that extent).

Please let me know if you need any more info etc.

Thanks for the great library BTW, it has been very useful to us 👍!

[kettanaito]

Hey, @bertdeblock. Thanks for your kind words!

I think .stop() used to return a Promise a very long time ago because it unregistered the worker. That's no longer the case, and now calling .stop() only sends a special event to the worker saying that it should ignore any requests coming from this particular client:

msw/src/setupWorker/stop/createStop.ts

Line 13 in 6e7ec28

context.workerChannel.send('MOCK_DEACTIVATE')

On the worker's side, this means removing the client's ID from the internal set of active client IDs:

msw/src/mockServiceWorker.js

Lines 64 to 67 in 6e7ec28

	case 'MOCK_DEACTIVATE': {
	activeClientIds.delete(clientId)
	break
	}

Once removed, all requests from this client will still be intercepted but not mocked. Instead, they will be performed as-is:

msw/src/mockServiceWorker.js

Lines 151 to 157 in 6e7ec28

	// Bypass initial page load requests (i.e. static assets).
	// The absence of the immediate/parent client in the map of the active clients
	// means that MSW hasn't dispatched the "MOCK_ACTIVATE" event yet
	// and is not ready to handle requests.
	if (!activeClientIds.has(client.id)) {
	return await getOriginalResponse()
	}

Do you mind setting a few breakpoints in the mockServiceWorker.js in your browser's DevTools and seeing what exactly happens when your request gets stuck?

Well, I think it's possible that a request happens, triggers the fetch listener, begins processing, and meanwhile .stop() is called, removing the client's ID. I'm still curious when exactly this hangs and why.

I guess we can consider making the deactivation events bi-directional so that the worker would send back something like DEACTIVATE_SUCCESS and the client will establish a Promise in .stop() awaiting that message.

[bertdeblock]

@kettanaito Thanks for the response. I will take some time to reproduce the issue and provide you with more detailed info. Won't be right away, but I'll make it happen!

[kettanaito]

Take your time. I'm looking forward to diving into this issue together. At this point, it's about learning as much as I can about the use case and providing you with proper guidance on how to achieve it.

[bertdeblock]

FWIW, this has become less of an issue for us.
We now have more control over the fetch call mentioned in the initial post.
Meaning, we can properly await the call and invoke worker.stop() afterwards.
Feel free to close this discussion if you see fit @kettanaito.
Thanks for the help!