Required service for type GraphQL.Types.LongGraphType not found occurred

[mariusbancila]

While starting up my GraphQL app (using the latest version of graphql-dotnet, 7.1.1) I get this error in the output window:

Required service for type GraphQL.Types.LongGraphType not found occurred

This is followed by:

Error: This graph type 'Query' has already been initialized. Make sure that you do not use the same instance of a graph type in multiple schemas. It may be so if you registered this graph type as singleton; see https://graphql-dotnet.github.io/docs/getting-started/dependency-injection/ for more info. occurred

(This later one is quite misleading. You need to fix the previous ones and then this one goes away. I was tricked by this for a while.)

But what service could be missing for LongGraphType?

[mariusbancila]

I found this in the sources:

        public static object GetRequiredService(this IServiceProvider provider, Type serviceType)
        {
            if (provider == null)
                throw new ArgumentNullException(nameof(provider));

            if (serviceType == null)
                throw new ArgumentNullException(nameof(serviceType));

            object? service = provider.GetService(serviceType);
            if (service != null)
                return service;

            throw new InvalidOperationException($"Required service for type {serviceType} not found");
        }

This is also misleading. It's not that a service is missing for the LongGraphType, the LongGraphType is a service that is missing.

[Shane32]

We should modify the error message to match the typical .NET message for this scenario.

But I'd really like to discover why it triggers the This graph type 'Query' has already been initialized error. Certainly it would seem that the two messages are unrelated. If you can provide a sample that reproduces the error, it would be helpful.

[mariusbancila]

If I add LongGraphType as a singleton service it works. But then I get the same error for other scalar types, like ByteGraphType, etc. Why do I have to register these? Did something change in the library? This was not needed.

[Shane32]

If you can provide a sample, then I can investigate.

[mariusbancila]

This happens because I replace obsolete calls such as:

var field = tableType.Field(
            columnTypeDT.GetType(),
            columnName,
            description: "...",
            resolve: ctx =>

with the following:

var field = tableType.AddField(
            new FieldType()
            {
            ResolvedType = columnTypeDT,
            Name = columnName,
            Description = "...",
            Resolver = new FuncFieldResolver<object>(ctx =>

When using Type instead of ResolvedType then the error is gone!

I am a bit confused about these two properties now. Because I used to use ResolvedType when adding a new field type like this. Example:

         type.AddField(new FieldType()
         {
            Name = "succeeded",
            ResolvedType = new BooleanGraphType(),
            Resolver = new FuncFieldResolver<object>(ctx =>
            {
               //...
            })
         });

[Shane32]

Type is .NET type of the graph type of the field, and ResolvedType is the instance of the graph type. During schema initialization, any fields without a set ResolvedType instance are set by pulling an instance from DI based on the type set in the Type field. The instance is cached and used for any other uses of the same type. During execution, only the ResolvedType property is used.

Usually only the Type property is set, as this pulls all graph types from DI and allows GraphQL.NET to ensure that the same instance of each type is used throughout the entire schema. It also allows you to utilize DI to override graph types as needed.

Regardless, using the ResolvedType property should work, as well as using obsolete methods. Certainly if you specify a instance with ResolvedType it should not be attempting to pull the type from DI.

If you can provide a sample schema configuration that reproduces the problem, I can investigate further. Thanks!

[sungam3r]

Regardless, using the ResolvedType property should work, as well as using obsolete methods. Certainly if you specify a instance with ResolvedType it should not be attempting to pull the type from DI.

Agree. Something wrong here. Need a repro.

[sungam3r]

@Shane32 close?

[Shane32]

Need more input to continue investigation. Closing.