Possible memory leaks in stitching

[benmccallum]

Describe the bug
We're seeing consistently climbing memory usage (very slow, abuot 50MB per hour), but only on the gateway service. I've swept through the HotChocolate.Stitching code and, with the help of this extension found some cases of IDisposable instances not being disposed of potentially and that need reviewing.

To Reproduce
Steps to reproduce the behavior:

1. Install the extension
2. Investigate the following locations in code that are giving warnings (green squigglies):
   1. HotChocolate.Stitching.Requests.StitchingContext - the ctor build a dictionary of RemoteRequestExecutor instances but never disposes of them. This is setup in DI as scoped, so the caching is only useful in the scope and they should be disposed of. Perhaps StitchingContext needs to implement IDisposable and dispose it's dictionary entries?
   2. HotChocolate.Stitching.Requests.MergeRequestHelper::DispatchResults - IQueryResult instances are being flagged
   3. HotChocolate.Stitching.Pipeline.HttpRequestClient::FetchAsync - IQueryResult instance being flagged
   4. Microsoft.Extensions.DependencyInjection.HotChocolateStitchingRequestExecutorExtensions::AddRemoteSchema and AddLocalSchema - line 241 RequestExecutorProxy is being flagged though maybe these are OK as they're singleton/static in nature, only created at schema build time?

Expected behavior
Hopefully less climbing memory, though it's a very slow burn up.

Desktop (please complete the following information):

• OS: Linux alpine containers
• Version HCv11.0.8

Additional context
We've profiled with dotMemory running 10 thousand queries against the gateway, with a variation of node queries (to test my custom node resolver) and other general queries to test stitching, and not noticed anything particularly dramatic or that stands out.

[michaelstaib]

I still think this is not a general problem since we have 11 in production since November with no memory leak.

[michaelstaib]

HotChocolate.Stitching.Requests.StitchingContext

The request executor are stored on the schema and cannot be disposed. They have to remain intakt since they are used by all instances. The dictionary itself will be GCed.

[michaelstaib]

Actually you could be right ben. Overlook one thing ... let me dig a little.... will come back to you.

[mlstubblefield]

I have some suspicions that this is true or was true in HC 10. I have some production memory dumps of an HC10 app that did stitching and has some references to HotChocolate.Execution.ResolverContext. It looks like there may be a Dictionary<string, object> that is holding onto byte arrays and Tasks may also be involved.

Below you can see memory dumps 5 days apart. With significant growth in memory usage (the 2nd column is the object count, the 3rd is the memory usage in bytes).