Tracking down memory issue

[Scong]

I'm running into a memory leak which I believe is related to our interaction with dependency injection. Our application is using graphql modules for dependency injection and mostly type graphql for resolver construction and such. In production I'm seeing that operation scoped dependencies are continually growing until our application crashes

Our integration with typegraphql looks something like this in: (createApplication)
schemaBuilder: ({ typeDefs, resolvers }) => mergeSchemas({ schemas: [typeGraphqlSchema], typeDefs, resolvers, }),

And has been working well.

I am still attempting to reproduce the true memory leak, but was not seeing memory grow in the same way through reproduction, so I'm thinking that there is another aspect to this that I am missing. (I've tried merging schemas similarly, and other simple variations, but no such luck)

We are using

Apollo-Express-Server
Graphql-modules 2

I've worked on a reproduction of some of my issues at

https://github.com/Scong/graphql-modules-memory-leak

Questions:

1. How should createOperationController be used?
   -I am seeing that the createOperationController injector does not appear to be triggering the onDestroy Operation, which I've been suspicious is causing my memory issue, but have been unable to prove it. (even with autoDestroy enabled)
   -It looks like when creating an operationController, there winds up being two competing operation scoped injectors. One available through execution context, one that is available from the newly created operationController.

2. Execution Context not available inside of Operation Scoped providers, is this expected?

• I was looking for a way to access the execution context injector in a data loader. (I can avoid by wrapping probably, thought it was interesting)

---

Steadily non destroyed injectable when using operation controller injector.
twoHeartCount: 117
oneHeartCount: 1
twoHeartCount: 118
oneHeartCount: 0
twoHeartCount: 117