msw: Failed to construct 'Response': The status provided (0) is outside the range [200, 599]

Environment

Name	Version
msw	0.25.0
browser	Chrome
OS	macOS

Request handlers

// ./mocks/handlers.js

import { graphql } from 'msw'

const handlers = [
  graphql.mutation('bookAppointment', (_req, res, ctx) => res(ctx.status(422, 'Error 422 custom'))),
]

export default handlers

// ./mocks/browser.js

import { setupWorker } from 'msw'
import handlers from './handlers'

const worker = setupWorker(...handlers)

export { worker }

// ./index.js

if (process.env.NODE_ENV === 'development') {
    const { worker } = require('./mocks/browser')
    worker.start()
}

Actual request

import gql from 'graphql-tag'

export default gql`
  mutation bookAppointment($input: AppointmentRequestInput!) {
    bookAppointment(input: $input) {
        ...
      }
    }
  }
`

Current behavior

When running the react application I’m getting the following logs:

[MSW] Mocking enabled.

index.js:1034 Uncaught RangeError: Failed to construct 'Response': The status provided (0) is outside the range [200, 599].
    at index.js:1034
    at ServiceWorkerContainer.<anonymous> (index.js:1200)

Obviously the MSW is not intercepting said mutation…

Any ideas? I’m guessing that I’m making a silly mistake that I’m not able to see -_-

Expected behavior

The only log I should see is the MSW getting initialise:

[MSW] Mocking enabled.

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 14
Comments: 27 (16 by maintainers)

Commits related to this issue

test: add reproduction for #529 — committed to mswjs/msw by timdeschryver 3 years ago
test: add reproduction for #529 — committed to mswjs/msw by timdeschryver 3 years ago
test: add reproduction for #529 — committed to mswjs/msw by timdeschryver 3 years ago

Most upvoted comments

Based on the amazing job done by @timdeschryver and other participants of this thread, I’ve added a pull request (https://github.com/mswjs/msw/pull/564) that should fix this issue. MSW will not attempt to construct a Response instance from an opaque response anymore as a part of its life-cycle events. This means you won’t get .on('response:bypass') invoked when an opaque response is received. This is the expected and desirable behavior in regards to CORS specification as you cannot manipulate an opaque response in JavaScript by design.

@lwhiteley, I confirm that the aforementioned pull request fixes the issue in your reproduction repository. Once more huge thanks for preparing that!

kettanaito on Jan 24, 2021

@lwhiteley my bad, I’ve indeed mixed those two issues. Thank you for preparing that repo, I’ll check it out and perhaps both issues will have the same cause.

kettanaito on Jan 12, 2021

@kettanaito

https://github.com/lwhiteley/msw-error-reproduce

here is a reproduction.

As you can see, i mocked the request but in the app i never actually invoke it … as this is a fresh create-react-app template without any mods except msw

unfortunately it doesnt happen all the time but im trying to replicate it definitely as it always happens in my app

lwhiteley on Jan 12, 2021

i assume it will be 0.26 @Justinohallo.

i have downgraded to 0.24 until the change has been released

lwhiteley on Jan 25, 2021

I created a reproduction in our test suite at https://github.com/mswjs/msw/tree/reproduce-529. I wasn’t able to reproduce this via a fetch request, but by adding an image to the page (this is also the case at https://github.com/mswjs/msw/issues/529#issuecomment-758666474).

I still think that we need to handle these responses differently, and current I’m thinking of the following options:

don’t send the response to the client (my least favorite)
send the response to the client, but not with a Response object, but with a custom object
send a different response to the client, either with a different object, or without an object since most of the response isn’t available

timdeschryver on Jan 23, 2021

I was planning on trying to reproduce this behavior in our test suites today, I’ll keep you updated.

timdeschryver on Jan 23, 2021

Seeing this as well after upgrading to 25.

Some debugging info here, looks like this one hasn’t been reported yet.

https://github.com/mswjs/msw/blob/f418117669ce40cc3d454759b1ccf570b35df1d1/src/utils/worker/createResponseListener.ts#L16

function createResponseListener(context) {
    return (_, message) => {
        const { payload } = message;
        if(!payload || !payload.status) {
            console.log('Payload status 0 or missing', payload);
            debugger
        }
        const response = new Response(payload.body, payload);
        ...

Active request on network tab is for react-devtools: chrome-extension://<some-hash>/build/react_devtools_backend.js

If I disable react-devtools extension I’m unable to reproduce this issue. Immediately when dev-tools are activated this issue comes up all the time. Should MSW somehow filter out these extension requests?

AriPerkkio on Jan 21, 2021

Having the same issue.

I have the exact set up as listed in the documentation.

Justinohallo on Jan 18, 2021

@kettanaito i think you’re mixing my specific issue with the issue of the original reporter. The original reporter has a graphql example.

Im saying that this same error happens for mocking rest endpoints (may be irrelevant) as well and my observations are purely based on behaviours i saw when i included the service worker in my app. When i disabled msw everything works fine

lwhiteley on Jan 12, 2021