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.

[kettanaito]

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]

@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.