Axios call with data doesn't match predicate with same path in 2.x

[jc-samcart]

Prerequisites

• I confirm my issue is not in the opened issues
• I confirm the Frequently Asked Questions didn't contain the answer to my issue

Environment check

• I'm using the latest msw version
• I'm using Node.js version 18 or higher

Node.js version

v20.9.0

Reproduction repository

https://github.com/jc-samcart/msw-example

Reproduction steps

yarn test

Current behavior

I have created a handler for posting to the bananas endpoint. When I make calls to this endpoint with axios, it only is captured if I don't provide any data to the post via axios. If data is provided, I receive AxiosError: Network Error

    http.post('https://localhost:2345/bananas', ({ request, params, cookies }) => {
        return HttpResponse.json({age: 7})
    }),

This post request works:

await axios.post('bananas');

This post throws an error:

await axios.post('bananas', {age});

Expected behavior

I would expect both axios post calls to match the handler. This did work in 1.x and I only encountered this error when upgrading to 2.x

[zigsong]

I have the exact same problem 🙁

[ilyaulyanov]

Hi @jc-samcart, wondering if you were able to find a workaround for this issue? I am experiencing it as well

[jc-samcart]

Hi @jc-samcart, wondering if you were able to find a workaround for this issue? I am experiencing it as well

@ilyaulyanov Not yet. I assumed I was doing something wrong rather than it being a code issue, so I've just been putting off upgrading.

[kettanaito]

I suspect this is the same problem as #1931. Jest -> JSDOM -> core-js -> cannot call structuredClone on ReadableStream (a polyfill's problem). Will post more once I look into this...

[kettanaito]

Root cause

So if we dive deeper into what causes the response error, we can find this:

error: ReferenceError: structuredClone is not defined
          at cloneBody (/msw-example/node_modules/undici/lib/fetch/body.js:277:21)
          at cloneRequest (/msw-example/node_modules/undici/lib/fetch/request.js:807:23)
          at Request.clone (/msw-example/node_modules/undici/lib/fetch/request.js:717:27)
          at HttpHandler.<anonymous> (/msw-example/node_modules/msw/lib/core/handlers/RequestHandler.js:116:43)

Somewhere along the line, the XMLHttpRequest interceptor has called .errorWith(). That happened because resolving the request has thrown an error (which you can see above). The interceptor treats any runtime errors as network errors since that what would happen if the server had that runtime error.

Granted, I think we should improve this behavior only in Node.js. I don't yet know how, since I don't want to dive back into guessing whether this was an intended exception thrown in the handler or an unexpected exception. But printing that original error would be nice. Perhaps we should store it in error.cause, given Axios and others can actually preserve that (I suspect not).

Based on the error, the structuredClone function that undici@6 uses to clone ReadableStream request/response bodies is missing in your test environment. This is really a shame because that's a standard function globally available in the browser and Node.js. Since you are using Jest+JSDOM, you don't get it.

Solution

There is no solution to this. Node.js doesn't export the structuredClone implementation as it references the internal binding written in C straight away (doesn't have a JavaScript counterpart). You cannot require it and so you cannot polyfill it yourself in jest.polyfills.ts as you do with other things thats JSDOM robs you off.

I recommend migrating to Vitest. Vitest respects your test environment and preserves Node.js globals even if using JSDOM. You are quite blocked by the obsolete tooling that at this point, so migrating to modern tooling is the way to go.

[kettanaito]

Regarding forwarding the original error, it's like I suspected: your request client will control whether that error is forwarded at all. For example, Axios uses XHR when it runs in JSDOM, and erroring an XMLHttpRequest doesn't accept any error as an argument (see this). Since using XHR is Axios' choice, you see how request client you are using controls how much information you get in case of errors.

[jc-samcart]

@kettanaito Appreciate your time looking at this. Just went through the process of updating to vitest using this nifty script and then the msw codemods. Everything is working as expected. Thank you!