Upgrade to Node.js 24: TypeError: RequestInit: Expected signal ("AbortSignal {}") to be an instance of AbortSignal.

[kleinfreund]

Because I'm unsure how to categorize the issue that I'm running into, I'm going to open a discussion rather than a bug report (as this might not be a problem with msw necessarily).

In a project that I'm upgrading from Node.js v23.11.1 to v24.1.0, I'm starting to see all tests that involve msw-mocked network requests fail with the following underlying exception upon creating a new Request():

TypeError: RequestInit: Expected signal ("AbortSignal {}") to be an instance of AbortSignal.
 ❯ Object.webidl.errors.exception node:internal/deps/undici/undici:4096:14
 ❯ Object.AbortSignal node:internal/deps/undici/undici:4338:31
 ❯ node:internal/deps/undici/undici:10747:41
 ❯ node:internal/deps/undici/undici:4389:16
 ❯ Object.RequestInit node:internal/deps/undici/undici:4371:21
 ❯ new Request node:internal/deps/undici/undici:10111:34
 ❯ Object.construct node_modules/@mswjs/interceptors/src/interceptors/ClientRequest/utils/recordRawHeaders.ts:185:33
 ❯ Proxy.request src/utilities/api.ts:86:21

The appearance of the @mswjs/interceptors in the stack trace is the reason why I ask this in context of msw first as the line of code referenced in the recordRawHeaders.ts file is part of the code that replaces the global Request object with a (fairly non-invasive) proxy.

Removing any code in my project that sets the RequestInit object's signal property avoids the problem.

What steps can I do to investigate/categorize this issue further so that I can report a bug in the right place?

The Node.js v24 release notes don't immediately strike me as containing a relevant breaking change (though the list of major changes under https://nodejs.org/en/blog/release/v24.0.0#semver-major-commits doesn't exactly make clear what was broken), but prior to me upgrading Node.js, the tests work fine.

Notes

• new Request('http://example.org', { signal: AbortSignal.timeout(1) }) executed in Node.js does not lead to the same exception
• To test the latest @mswjs/interceptors version, I manually overrode the version to 0.39.2 while testing this
• Possibly related to Using AbortController with fetch throws an error with Node 24 + jsdom vitest-dev/vitest#8374

[reckseba]

To the maintainers of this repo: Is an update to undici v7 planned?

[kettanaito]

We don't depend on undici so there's nothing to update. You see Undici in stack traces because Node depends on it.

[reckseba]

Oh right. Sorry, spotted it in the package.json, but it is in devDependencies. Thank you!

[kettanaito]

Thanks for reporting this. Looks like a classic mismatch of dependency versions to me. I'm trying to see what we do in Interceptors to have caused that...

As of now, MSW doesn't offer official support for Node.js v24 so it's hard for me to categorize this as an issue. I hope we can ditch recordRawHeaders() in the future versions of Interceptors, but we'll cross that bridge when we come to it.

I wonder why exactly this issues happens. Our proxy wraps the global Request and constructs it as-is using Reflect.construct(). We are not patching or modifying any classes in a way that would warrant instance check failures. Proxies path instance checks because they are transparent:

class A {}
let a = new A()
let b = new Proxy(a, {})
b instanceof A // true

@kleinfreund, I could use your help getting to the bottom of this, if you have the time. If we can track down what causes this, we can address it and publish a fix. It's also worth raising this in the Undici's repo as the folks there have more context around Node.js releases and version compatibility. Thanks.

[kleinfreund]

Happy to help, of course. But I'm a little stumped with regards to how this could fail now. I tried to piece together a minimal reproduction that gives me an indication of at least the code involved that causes this.

Creating a proxy for Request just like the interceptors package does doesn't seem to cause any issues by itself and I was able to construct such a Request including a AbortSignal just fine.

With Node 24 upgrading undici to v7 (https://nodejs.org/en/blog/release/v24.0.0#undici-7) and Undici v7 announcement post making note of Stricter fetch() spec compliance, that's possibly where this issue arrises.

I should have some time later to run some more experiments.

Some more observations:

• Cloning @mswjs/interceptors, building and running the three test suites all pass on the project's .nvmrc Node version; once I switch to Node 24, I get two unit test failures (in the calculates body length from the FormData request/response body tests) and 3 node test failures (returns the request url for a cloned mocked response, supports mocking non-configurable responses, fetch: emits the "response" event upon a mocked response) which doesn't immediately look related (though they do start with v24, v22 is fine).

[kleinfreund]

Anything I can do to investigate this further? I'm not really sure what good next steps would be.

Update: Nothing to be done here anymore. See #2530 (comment).

[kleinfreund]

There's a good chance the next major version of vitest, version 4, addresses this by fixing vitest-dev/vitest#8374 with vitest-dev/vitest#8390.

Installing [email protected], I do get some errors, but I get the same errors without upgrading to Node.js 24 meaning that the issue outlined here is no longer there.

In other words: this wasn't an issue with msw.