Ben Newman

> I don't really understand what the purpose of this warning is – in case the "missing" module is really missing at execution time, the app will crash anyway and...

@defrex Could you try `npm i @apollo/client@beta`? The upcoming v3.6 release has a number of improvements/fixes for `useLazyQuery`.

@igdev116 (and others) Could anyone put together a quick [reproduction](https://github.com/apollographql/react-apollo-error-template), so I can test a potential solution I have in mind?

Just to add another diagnostic to the mix, I would encourage everyone to try running `npm i @apollo/client@next` (to get version 3.6.3). I doubt everyone's issues will be fully addressed...

@AlexMost For SSR, our blanket recommendation† is to create a new client for each request, letting the old ones be garbage-collected. If you do that, this memory leak should stop...

@AlexMost PR in progress: #7943

@AlexMost This should be (at least partially) fixed in `@apollo/[email protected]` (just published to npm). Please let us know if you (don't) see an improvement after updating!

@AlexMost Adding to @hwillson's comment, it's possible you're still using the v3.3.13 code in Node.js despite changing the `getDataFromTree.js` module, since Node uses the CommonJS bundles rather than separate ESM...

@AlexMost If you have a chance to try `@apollo/[email protected]`, it contains 496b3ec2da33720d6444c4b4a7d4b44a4d994782, where I made the `RenderPromises` class more defensive about not accepting new data after `renderPromises.stop()` is called. This...

@dchenk Are you clearing/resetting that `apolloClient` instance somehow between requests? I just noticed that `ObservableQuery#reset` does not call `this.watches.reset()` as it probably should, so that might be an avenue to...