Msw: Node env - When using HTTP error code in a response, statusText is set to null

Created on 15 Jul 2020  路  8Comments  路  Source: mswjs/msw

First of all, thanks a lot for MSW, it's really cool 馃憤

Describe the bug

When using HTTP error code in a response, statusText is set to null. It's in node environment.

Environment

  • msw: 0.19.5
  • nodejs: 12.18.0
  • npm: 6.14.5

Please also provide your browser version.

To Reproduce

Steps to reproduce the behavior:

  1. Setup a response with an error code:
return res(
      ctx.status(401),
      ctx.json({
        message: 'Mocked response JSON body',
      }),
);
  1. If you parse statusText to format an error message, you can see null value:
{
    "statusCode": 401,
    "message": "null: Mocked response JSON body"
}

Note, same happens if you provide custom statusText like so ctx.status(401, 'Test')

Expected behavior

Response should contain correct default statusText. Also it should be replaced by a custom one, if provided:

{
    "statusCode": 401,
    "message": "Unauthorized: Mocked response JSON body"
}

Screenshots

None

bug node

Most helpful comment

The scenario has been tested and the fix has been released in [email protected] (see Release notes).

@marcosvega91, please, do you mind carrying over the update of the dependency in MSW? Feel free to use pull requests like this as an inspiration.

All 8 comments

Hi @m0t0r thanks for opening the issue :),

it should work as you expected. Can you create a repo with a reproduction case?, in this way I can take a look at the code to understand why it's not working.

Thanks, @m0t0r for reporting this, and @marcosvega91 for taking over!
I'll share all the technical details I know about this, maybe this helps.

ctx.status utility inherits a status message respective to the given status code:

https://github.com/mswjs/msw/blob/be0173d6cd4efc9e06c9e4e6f3ff771e77c56708/src/context/status.ts#L10-L11

That statusText is set on the mocked response object, but that doesn't necessarily means it propagates to the client. Mocked response object is mapped to the response instance manually. For example, this is how it's mapped to a Response on the Service Worker's side:

https://github.com/mswjs/msw/blob/be0173d6cd4efc9e06c9e4e6f3ff771e77c56708/src/mockServiceWorker.js#L205-L208

clientMessage.payload contains the mocked response object with the statuText: string property set.

In NodeJS request interception here's how the mocked response object is mapped to the instance that node-request-interceptor (NRI) library would understand:

https://github.com/mswjs/msw/blob/be0173d6cd4efc9e06c9e4e6f3ff771e77c56708/src/node/setupServer.ts#L83-L88

response.statusText is present here, so we should be fine.

Once NRI received a mocked response object, it converts it to the proper response based on how the request has been issued (via http, or XMLHttpRequest). Here's the relevant parts:

  • ClientRequest mapping of response.status:

https://github.com/mswjs/node-request-interceptor/blob/cf8d93771601207edd7a6b5e3b0e28a7372c2503/src/http/ClientRequest/ClientRequestOverride.ts#L186

Notice how there is no response.statusText mapping at all. I believe that is the issue.

  • XMLHttpRequest mapping of this.status and this.statusText:

https://github.com/mswjs/node-request-interceptor/blob/cf8d93771601207edd7a6b5e3b0e28a7372c2503/src/XMLHttpRequest/XMLHttpRequest/createXMLHttpRequestOverride.ts#L256-L257


Starting with a test is always a way to go. This doesn't look like an issue on the MSW side, rather on the NRI side. Let me know if you have any questions. Thanks.

@marcosvega91 @kettanaito please check this repo with reproduction of the issue: https://github.com/m0t0r/msw-statusText-issue-repro

ok I have found the issue, I'll make a PR on node-request-interceptor.

The problem is that statusText from mockedResponse is not assigned to statusMessage of response object

https://github.com/mswjs/node-request-interceptor/blob/cf8d93771601207edd7a6b5e3b0e28a7372c2503/src/http/ClientRequest/ClientRequestOverride.ts#L186

Awesome, @marcosvega91! Looking forward to the pull request. Will help with the code review.

done, let me know :)

@marcosvega91 thanks a lot for the fix!

The scenario has been tested and the fix has been released in [email protected] (see Release notes).

@marcosvega91, please, do you mind carrying over the update of the dependency in MSW? Feel free to use pull requests like this as an inspiration.

Was this page helpful?
0 / 5 - 0 ratings