Msw: Always receiving TypeError: Network request failed

[spruce-bruce]

Describe the bug

In my jest tests, if I call server.listen() all of my network requests inside of the test fail with the generic fetch error TypeError: Network request failed. These requests succeed if I don't attempt to run msw at all.

The failure occurs for EVERY request, regardless of whether or not msw has a handler that matches the request or not.

My test looks something like this:

import { setupServer } from "msw/node";
import { rest } from "msw";

const handlers = [
  // behavior is the same regardless of whether or not I have any handlers defined
];

const server = setupServer(handlers);
describe("Some Thing", () => {
  beforeAll(() => server.listen());
  afterEach(() => server.resetHandlers());
  afterAll(() => server.close());

  test('example test', () => {
    await fetch(
      "https://api.fake.com/something/i/know/works",
      {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
        },
        body: JSON.stringify({ foo: "bar" }),
      }
    );
  })
}

I am adding react-testing-library tests (using msw on the recommendation of KCD) to an older react application. The app was created with CRA ~3.5 years ago. I've updated react-scripts to a more recent version just in case this was the cause, but I've had no luck.

I think it's likely that either my configuration is wrong, or that I have a dependency problem, but the error from fetch is so opaque that I'm finding myself stuck. I don't know if there are any debug tools available to inspect or trace the path of this these failing requests to find out where they're getting jammed up.

Environment

My react application sits in a yarn workspace monorepo, but when I isolate the app from its "siblings" and just do npm i && npm test I see the same behavior.

• msw: 0.21.2
• nodejs: 10.18.1 & nodejs: 12.16.3
• npm: 6.14.4
• yarn: 1.22.4
• react-scripts: 3.2.0 which installs jest: 24.9.0
• I run my tests with jest-environment-jsdom-sixteen: 1.0.3

To Reproduce

I'm not yet sure how to reproduce. I'm not even sure if this is a real bug. I think it's most likely a misconfiguration on my part or a weird dependency issue.

Expected behavior

I expect that network requests are either handled by msw handlers or are passed through to be handled by the network.

[spruce-bruce]

I'm going to try and set things up in a "pure" environment and try and repro. If I can't repro I'll add deps one at a time until I find the failure (or don't).

[marcosvega91]

Hi @spruce-bruce thanks for raising this 😄

You should call setupServer in this way setupServer(...handlers). Let me know if this will solve your issue.

Thanks

[spruce-bruce]

Well that did it. I feel like a dummy, but that probably saved me another 4-8 hours of time so thank you a LOT!

I promise I have the setupServer() docs open and have been reading through them looking for my mistake. I don't know where I got the idea that this function could take an array.

I'm happy to close this (or for you to close this).
This problem was particularly difficult for me to solve on my own through normal debugging and googling and closed issue skimming and all that. Do you think there's anything that should be done (throw?) when the server is set up so incorrectly that it breaks every network request?

[marcosvega91]

I know the library but sometime I make the same mistake hahahaha. I think that also other people can have this kind of problem, maybe we can add a check on setupServer and setupWoker functions. What do you think?

[spruce-bruce]

That would certainly have helped save me a big chunk of time. I'm brand new to msw so I'm not entirely sure what the preference would be there.

My instinct is to do some kind of assertion about the type of the variable(s) being passed into setupWorker and setupServer and throw on a mismatch, but I know there can be debate about this kind of a pattern.

[marcosvega91]

Hi @spruce-bruce what do you think of this check? This can be added also on setupServer function

diff --git a/src/setupWorker/setupWorker.ts b/src/setupWorker/setupWorker.ts
index 7e4caf3..9f490cd 100644
--- a/src/setupWorker/setupWorker.ts
+++ b/src/setupWorker/setupWorker.ts
@@ -42,6 +42,14 @@ let listeners: Listener[] = []
 export function setupWorker(
   ...requestHandlers: RequestHandlersList
 ): SetupWorkerApi {
+  requestHandlers.forEach((handler) => {
+    if (typeof handler !== 'object' || !('parse' in handler))
+      throw new Error(
+        `[MSW] The handlers passed to setupWorker function are not of the right type.
+          A common mistake is to call setupWorker in this way setupWorker(requestHandlers),
+          you should instead call it as setupWorker(...requestHandlers)`,
+      )
+  })
   const context: SetupWorkerInternalContext = {
     worker: null,
     registration: null,

[kettanaito]

Perhaps let’s check if the given handlers are not an Array? Throw an error in that case.

[marcosvega91]

requestHandlers is always an array because it will contain all the args. We could, of course, check if the first element of requestHandlers is an array and do the following

diff --git a/src/setupWorker/setupWorker.ts b/src/setupWorker/setupWorker.ts
index 7e4caf3..f35391d 100644
--- a/src/setupWorker/setupWorker.ts
+++ b/src/setupWorker/setupWorker.ts
@@ -42,6 +42,13 @@ let listeners: Listener[] = []
 export function setupWorker(
   ...requestHandlers: RequestHandlersList
 ): SetupWorkerApi {
+  requestHandlers.forEach((handler) => {
+    if (Array.isArray(handler))
+      throw new Error(
+        `[MSW] setupWorker function receive every handler as an arg.
+          You should call it as setupWorker(...requestHandlers) with requestHandlers the array of handlers.`,
+      )
+  })
   const context: SetupWorkerInternalContext = {
     worker: null,
     registration: null,

[spruce-bruce]

I'm not familiar enough with the internals to contribute to the conversation about how best to do the type check, but it seems like either of those options would work well from the perspective of the client code!

[benschac]

I had the same issue.TypeError: Network request is extremely hard to understand. It took me quite a bit of time to debug, as well. I also noticed that you'd get this error when you have an undefined variable in your request handler. More specific error messages would be welcomed.

[kettanaito]

The fix has been merged and more useful error messages will be published in the next release. Thanks to everyone for contributing.