RTKQ + redux-dynamic-middleware: Maximum call stack size exceeded

[pavandv]

This is a duplicate of #1381

Quoting a comment below by @travenec from the mentioned issue, is exactly the problem I'm facing with RTKQ.

Thank you for pointing me in the right direction. That was actually something I wanted to ask originally as well - do I need more middlewares if I use createApi more times (a middleware for each api) or a single set of middlewares is enough? If single (which is then common for all apis), your idea would be even better than any other solutions.

The problem araises when you have multiple api targets (different servers). From what I understand, you cannot really have a createApi targeting https://apiserver.com/api and then just add endpoints targeting other e.g. https://otherserver.com/api. Therefore I don't see that as solution. Feel free to correct my ideas...

We are using Redux store and RTKQ in our Micro Frontends, where a single store is been created in our Base App and child MFE's have their own createAPI pointing to different domains mentioned in the quote and has to inject the respective createAPI's to the Store at our Base APP.

Although we are able to inject the reducers, adding middleware dynamically using redux-dynamic-middlewares is causing Maximum call stack size exceeded error.

How can we inject such Middleware dynamically for given use case?

[phryneas]

I'm honestly a bit irritated by that error message. I know it comes up, but I'm not quite sure why.

Yes, the RTKQ middleware is made internally of about 5-10 middlewares and as middlewares, those call each other, increasing the stack size.

But that should not be a real problem - this will maybe end up with a stack depth of 50 or 100, and JavaScript can go thousands of recursive calls deep.

So... if you have a good reproduction of that and want to make a replay, that might help us to actually look into that.

[markerikson]

While it's not immediately related: I'll say that I'm not a huge fan of how RTKQ's "middleware" is really 10 separate middleware combined together. And yeah, I can see that if you were to add 2-3 API slice middlewares to the store, that's a lot more to the stack size on every dispatch.

I don't have an immediate answer for how we might rework those internals, though.

[markerikson]

@pavandv : I actually just put up a PR that optimizes the internal implementation of RTKQ's middleware:

#2641

Out of curiosity, can you try the CodeSandbox CI preview build from that PR in your app, and see if it fixes the issue?

But also yeah, if you could provide a CodeSandbox / Github repo / Replay ( https://replay.io/record-bugs ) of this error happening, it would be really helpful.

[pavandv]

Thank you for all your prompt replies. Right now I'm away from my laptop.

I'll definitely try out the refactored version from the above PR, as well as create a sample project reproducing the mentioned issue and share the link.

Although I think I can only do that tomorrow. Please excuse my delay. Appreciate your understanding. Thank you!!

[phryneas]

No need to rush 🙂 This fix is in the newest 1.9 alpha release, so you can try it there. But for now, just enjoy your weekend!

[pavandv]

Just tested with 1.9 alpha release. The issue is resolved 😄. I can also dynamically inject my entire API slice including with middlewares.

Thank you so much for resolving this over night. Appreciate it a lot.

When can we expect 1.9 official release?

[phryneas]

I think at this time we have two issues open which still require some discussion:

• Auto batch enhancer #2621
• [breaking fix] replace getRunningOperationPromise(s) with getRunning(Query|Queries|Mutation|Mutations)Thunk #2481

apart from that it's pretty feature-complete. But these two might take quite some time until we get to a decision.

[pavandv]

Sounds good. If I may ask, Please don't close this issue until 1.9 released. I'll be watching this to get notified.

[phryneas]

@pavandv you can also subscribe to releases:

[markerikson]

Yeah, I actually am going to go ahead and close this issue so we know it was resolved as part of 1.9 and there isn't work left to do here. Thanks!

[shth]

Hi @markerikson @phryneas I have tried both the 1.9.0-alpha.0 and 1.9.0-alpha.1 version of redux toolkit with redux-dynamic-modules, but seems like it still got the maximum call stack size exceeded error.

It works fine if I comment out the line

// store.ts
middlewares: [api.middleware]

Here's a minimal setup for your reference:
https://codesandbox.io/s/rtk-query-selectfromresult-forked-630llq?file=/src/store.ts

Thanks!

[phryneas]

Seems to me like an inconsistency between applyMiddleware and their code here:

https://github.com/pofigizm/redux-dynamic-middlewares/blob/master/src/index.js#L8-L13

I think this behaviour causes an infinite loop in combination with

redux-toolkit/packages/toolkit/src/query/core/buildMiddleware/index.ts

Lines 72 to 78 in d9e481b

	return (next) => {
	return (action) => {
	if (!initialized) {
	initialized = true
	// dispatch before any other action
	mwApi.dispatch(api.internalActions.middlewareRegistered(apiUid))
	}

which will dispatch an action once per new store the middleware is attached to.

Either way, I'd say this seems to be a bug in that redux-dynamic-middlewares package.

[phryneas]

Looking in the debugger, the code of redux-dynamic-middleware used here is actually not the above code snippet, but

  var enhancer = function enhancer(store) {
    return function (next) {
      return function (action) {
        var chain = allDynamicMiddlewares.map(function (middleware) {
          return middleware(store);
        });

        return _redux.compose.apply(undefined, chain)(next)(action);
      };
    };
  };

which will definitely trigger that bug, since it recreates the chain on each action dispatch, resetting the full internal middleware state every time.

Maybe that's an old version of that package? See https://630llq.csb.app/node_modules/redux-dynamic-middlewares/lib/index.js