MaxListenersExceededWarning is shown by React.StrictMode

[yunics-highfield]

I have a React project with msw. MaxListenersExceededWarning is shown on console when I use React.StrictMode and fetch about 10 or more mock data on my application. I'd like to resolve it. How do you guys treat with it below?

Emitter.js:89 MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 response:mocked listeners added. Use emitter.setMaxListeners() to increase limit

[e-krebs]

bumping this as I'm facing the same issue when running tests with jest & msw as soon as 10 handlers are set.
@yunics-highfield did you find a solution?

[yunics-highfield]

@e-krebs No. I'm still facing the warning...

[mattcosta7]

v2 tries to handle this https://github.com/mswjs/msw/blob/c27c32000d64bb285998597deacbfc8349f08a55/src/node/setupServer.ts#L21C1-L43

but it's possible we're not setting this high enough

[mattcosta7]

I think it's also possible that because of the number/location of clones, we might need additional places where we set this. We may be able to just decrease the number of clones too, although that would never fix it completely.

The important thing is, there isn't an actual problem. Node is just warning eagerly, but this isn't actually a thing that matters

[e-krebs]

what worked for me (I had to do both):

• calling server.use once, i.e. building a handlers list and calling server.use once with it vs. calling server.use multiple times
• I had some navigation occurring. I had to catch those by mocking react-router-dom's useNavigate.

[mattcosta7]

interestng, server.use shouldn't really impact th number of listeners on msw's side. The total number of handlers has some impact on this (and more than 1x per handler that we set now, but situationally dependant).

navigation also shouldn't, unless that was causing other handlers to be hit? Annoyingly the node warnings for this don't tell you what eventtarget is warning

[mattcosta7]

Looks like this should be relatively unrelated to strict mode, since it's per-request listeners, but I've reproduced this in a test - #1910 and we can work on improving the cause, but there's no actual issue besides some log noise

[mattcosta7]

Opened #1911 to track