msw: Request body with Protobuf binary data is corrupted

Prerequisites

Environment check

  • I’m using the latest msw version
  • I’m using Node.js version 14 or higher

Browsers

Chromium (Chrome, Brave, etc.), Firefox

Reproduction repository

not easily possible

Reproduction steps

Good news, I saw some issues with people having problems(?) mocking binary protobuf messages. I can confirm it works though for Twirp (which is like gRPC but simplified). Simply encode and decode with a properly set header

Well, mostly: My input

const input = new Uint8Array([138, 1, 6, 10, 4, 10, 2, 32, 1]);

I can encode/decode without issues before sending to msw, but in the mock itself it turns into either:

const usingArrayBuffer = new Uint8Array(await req.arrayBuffer());
value usingArrayBuffer = Uint8Array([239, 191, 189, 1, 6, 10, 4, 10, 2, 32, 1]);

or with a little (unsuccessful) hacking:

const usingText = new Uint8Array((await req.text()).split("").map(x => x.charCodeAt( 0 )));
value usingText = [ 253, 1, 6, 10, 4, 10, 2, 32, 1 ]

usingText[0] = 138 ‘fixes it’, but unfortunately doesn’t work in all cases

Notice the values [239, 191, 189, ...], that’s a unicode replacement character. As in, the arrayBuffer has been at some point converted from raw data to a string and ‘back’ (?)

A likely important note: I use msw-storybook-addon

EDIT: whilst writing this I think I realize the problem. That addon has version

  "peerDependencies": {
    "msw": ">=0.35.0 <1.0.0"
  },

set. Which doesn’t contain the fixes I think I need.

I’ll likely have to open an issue there. But leaving this here for completeness/cross reference

Current behavior

arrayBuffer is stringified

Expected behavior

arrayBuffer is completely untouched

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 2
  • Comments: 15 (12 by maintainers)

Most upvoted comments

Small experience report: I was also having issues with corrupted request data in a PDF file upload mock endpoint (using version 0.46.1). The corruption looked just like the one described in this issue. After upgrading to msw@next there is no corruption anymore 😃