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

[dgilleland]

Hi @yunics-highfield ,

Although the msw docs don't mention it, if you're using msw as part of your testing suite and the specifics of your problem are because of listeners on the server.events, the fix might simply be to remove the listeners after each test:

    afterEach(() => {
        server.events.removeAllListeners();
        server.resetHandlers();
    });

---

@kettanaito : I'm not sure if the msw docs would benefit with this suggestion in regards to msw for testing scenarios. Also not sure if it's relevant to the issues/fixes that @mattcosta7 was doing in #1911 and #1914.

In any case, these back links might help future visitors. I also commented in this discussion.

[mattcosta7]

Also not sure if it's relevant to the issues/fixes that @mattcosta7 was doing in #1911 and #1914

Hey @dgilleland - I don't think it's related to the fixes I implemented. We had been cloning requests multiple times, which was assinging listeners to each of the request clones, which was causing standard usage to have those event listener errors, since the number of listeners was growing at a rate tied to the number of handlers that a request was processed by. My PR referenced above cached those parses/clones to be re-used between handlers in order to avoid

it might make sense to add something here: https://mswjs.io/docs/api/life-cycle-events/#precautions like "don't forget to cleanup event listeners properly

we do mention these in the docs, but not with an explicit reminder to do so https://mswjs.io/docs/api/life-cycle-events/#removing-listeners