Shane Krueger

Regardless of whether we would like it to be supported, it completely breaks GraphQL.NET right now. Middleware is just one example. Multithreading issues, scoped graph types, and memory leaks are...

It is completely impossible with the current design to support multiple schema instances accessing the same instances of graph types. I do think this is a worthy goal but this...

All this will do is make the *** countless *** issues arising from sharing graph types harder to identify the cause of.

Considering a singleton schema and singleton graph types: it is still subject to problems with middleware, the name converter and multithreaded initialization. Even if everything worked the question is: why?...

> I remember this and still think that this does not solve the problem. Agree. It was intended to be a start. But I do not mind if we have...

Sounds good. I'd like to consider refactoring the complexity analyzer into a validation rule and removing all complexity-specific code from ExecutionOptions, etc -- possibly moving to a separate nuget package...

Sounds good to me

> > whereas the former creates an instance of TypeInfo during fragment analysis > > Where? In the PR that was just merged https://github.com/graphql-dotnet/graphql-dotnet/pull/3159/files#diff-f4a29656e8af8665e2803754180c77667b11b6eb6c3a11f11026fd45bdc7f0d5R20-R35

I agree, which is why I brought it up. I can write a PR to refactor the complexity analyzer into a validation rule, if I have time.

I guess I meant to say that `TypeInfo` is normally only created once while validating the entire document, whereas with the complexity analyzer it now is created twice - once...