Hotchocolate: Using Connection Types In An Interface Throws Error The name `IConnection` was already registered by another type.

Created on 25 Mar 2020  路  10Comments  路  Source: ChilliCream/hotchocolate

Describe the bug
Version 10.4.0

I have an interface that contains a graphql relay field.

using HotChocolate.Types;
using HotChocolate.Types.Relay;

    public class SubjectInterface : InterfaceType<ISubject>
    {
        protected override void Configure(IInterfaceTypeDescriptor<ISubject> descriptor)
        {
            descriptor.Name("SubjectInterface");
            // This introduces some conflict into the schema
            descriptor.Field("records").AddPagingArguments().Type<ConnectionType<SubjectItemInterface>>();

        }
    }

And then two objects that implement that interface in exactly the same way, This is currently a base case before I add more fields to the different implementations

public class SubjectType : ObjectType<Subject>
    {
        protected override void Configure(IObjectTypeDescriptor<Subject> descriptor)
        {
            descriptor.Field<SubjectResolver>(t => t.GetRecords(default, default));
        }
    }

And the resolver for the object:

public class SubjectResolver
    {
        [UsePaging]
        public async Task<IEnumerable<ISubjectItem>> GetRecords(
            [Service] ISubjectItemService subjectItemService,
            [Service] IResolverContext context)
        {
            return await subjectItemService.GetSubjectRecords(context.Parent<ISubject>());
        }
    }

The error this then throws is:
HotChocolate.SchemaException: The nameISubjectItemConnectionwas already registered by another type. - Type: ISubjectItemConnection

I can also reproduce this if I have only one implementation of the ISubject interface.

As well as if I change the definiton of the records field to descriptor.Field("records").UsePaging<SubjectItemInterface>();

馃攳 investigate

All 10 comments

Could you post ISubject as well?

I already see the issue I think ... no need for ISubject

public interface ISubject
{
      const string TypeName = "subject";
      Guid Id { get; set; }
      DateTime CreatedAt { get; set; }
      bool Active { get; set; }
}

In which location do I remove ISubject? Removing ISubject from the interface type causes the same issue.

Can you build a small repro of your issue? that would be a great help.

@PascalSenn looks like in this case we are creating two connection types... how are we handling filters on interfaces?

@michaelstaib only of the interface properties

Great thanks.... we will start looking into it.

I have now looked at your project. Sorry for the long delay ... I always have a large backlog.

You have actually multiple issues here.

For instance you are using relay types and implementing the node interface which demands the id field to be of ID type but right after declaring it correctly you are overwriting it with UUID.

Regarding the paging attribute... since you declare a specific schema type in your interface you need to use that also in the attribute.

[UsePaging(SchemaType = typeof(SubjectItemInterface))]
        public IQueryable<ISubjectItem> GetItems(
            [Service] ISubjectItemService subjectItemService,
            [Service] IResolverContext context)
        {
            return subjectItemService.GetSubjectItems(context.Parent<ISubject>());
        }

While mixing and matching works, when starting with hot chocolate it is good to stick to one approach which will lead to a better understanding of it and to better code. When you have mastered it it can be quite useful to mix and match between code-first variants.

Thank you.

I did not realise that specifying the id field in the node would result in it casting it to a Uuid type instead of keeping it as an id field as i thought that was the specification

Was this page helpful?
0 / 5 - 0 ratings

Related issues

IKolosynskyi picture IKolosynskyi  路  3Comments

nigel-sampson picture nigel-sampson  路  5Comments

sfmskywalker picture sfmskywalker  路  3Comments

marcin-janiak picture marcin-janiak  路  4Comments

nigel-sampson picture nigel-sampson  路  5Comments