Resolver methods on objects not generated or missing arguments

[henrywoody]

What happened?

I've noticed some strange behavior with the generation of resolver methods that belong to specific objects (rather than to the root query).

In some cases the resolver method is not generated at all (in cases where I believe the method should be generated), in other cases the resolver method is generated but does not include the arguments specified in the schema.

In most cases the resolver method is correctly either generated or not generated, but the cases mentioned above differ from my expectation of behavior.

Here is an outline of setup and resulting behavior that I've worked out:

• (MethodName) Setup — Result
• (DoesNotMakeResolver1) Matching method (by name) on object type exists but takes no arguments and has correct return values — No resolver generated (incorrect)
• (DoesNotMakeResolver2) Matching method on object type exists but takes an argument defined by the resolver method (but not those defined by the schema) and has correct return values — No resolver generated (incorrect)
• (DoesNotMakeResolver3, DoesNotMakeResolver4) Matching method on object type exists and takes an argument (but not all) defined by the schema method (but not those defined by the resolver, i.e. ctx) and has correct return values — No resolver generated (incorrect)
• (CorrectlyDoesNotMakeResolver) Matching method on object type exists and takes all arguments defined by the resolver and schema and has correct return values — No resolver generated (correct)
• (MakesResolverButMissingArguments) Matching method on object type exists but lacks arguments defined by the schema and has differing return type from resolver — Resolver generated (correct) but missing arguments defined in the schema (incorrect)
• (MakesResolverWithAllArguments) Matching method on object type exists and has all arguments defined by the resolver and schema but has differing return type from resolver — Resolver generated with correct arguments (correct)
• (MakesResolver1) Matching method on object does not exist — Resolver generated (correct)
• (MakesResolver2) Matching method on object exists and takes arguments whose types do not match those of the resolver/schema — Resolver generated (correct)
• (MakesResolver3) Matching method on object exists and takes all correct arguments but argument names do not match (types do) — Resolver generated (not sure but I lean to incorrect)

There are likely some other cases but these are the ones that I've found and that matter to my usecase.

What did you expect?

I expect a resolver method to be generated if there is no existing method with all the correct arguments and the correct return values. And I expect no resolver method to be generated if such a method exists. Finally, if a method is generated, I expect its signature to include the arguments specified in the schema.

Minimal graphql.schema and models to reproduce

Schema

type Query {
    modelA(ID: ID!): ModelA!
}

schema {
    query: Query
}

type ModelA {
    ID: ID!
    DoesNotMakeResolver1(x: Int): Int
    DoesNotMakeResolver2(x: Int): Int
    DoesNotMakeResolver3(x: Int): Int
    DoesNotMakeResolver4(x: Int, y: Int): Int
    CorrectlyDoesNotMakeResolver(x: Int): Int
    MakesResolverButMissingArguments(x: Int): Int
    MakesResolverWithAllArguments(x: Int): Int
    MakesResolver1(x: Int): Int
    MakesResolver2(x: Int): Int
    MakesResolver3(x: Int): Int
}

Models

package main_model

import "context"

type ModelA struct {
	ID int `json:"ID"`
}

func (a *ModelA) DoesNotMakeResolver1() (int, error) {
	return 1, nil
}

func (a *ModelA) DoesNotMakeResolver2(ctx context.Context) (int, error) {
	return 1, nil
}

func (a *ModelA) DoesNotMakeResolver3(x int) (int, error) {
	return 1, nil
}

func (a *ModelA) DoesNotMakeResolver4(x int) (int, error) {
	return 1, nil
}

func (a *ModelA) CorrectlyDoesNotMakeResolver(ctx context.Context, x int) (int, error) {
	return 1, nil
}

func (a *ModelA) MakesResolverButMissingArguments(ctx context.Context) (float64, error) {
	return 1.0, nil
}

func (a *ModelA) MakesResolverWithAllArguments(ctx context.Context, x int) (float64, error) {
	return 1.0, nil
}

func (a *ModelA) MakesResolver2(x float64) (int, error) {
	return 1, nil
}

func (a *ModelA) MakesResolver3(ctx context.Context, y int) (int, error) {
	return 1, nil
}

Resulting Resolvers

func (r *modelAResolver) MakesResolverButMissingArguments(ctx context.Context, obj *main_model.ModelA) (*int, error) {
	panic(fmt.Errorf("not implemented"))
}

func (r *modelAResolver) MakesResolverWithAllArguments(ctx context.Context, obj *main_model.ModelA, x int) (*int, error) {
	panic(fmt.Errorf("not implemented"))
}

func (r *modelAResolver) MakesResolver1(ctx context.Context, obj *main_model.ModelA, x *int) (*int, error) {
	panic(fmt.Errorf("not implemented"))
}

func (r *modelAResolver) MakesResolver2(ctx context.Context, obj *main_model.ModelA, x *int) (*int, error) {
	panic(fmt.Errorf("not implemented"))
}

func (r *modelAResolver) MakesResolver3(ctx context.Context, obj *main_model.ModelA, x *int) (*int, error) {
	panic(fmt.Errorf("not implemented"))
}

Final Comments/Questions

Much of the unexpected behavior seems like a bug because the missing resolvers have methods that do not match the types/arguments that the resolvers require. Given that, is there a way I can change the configuration so that methods on objects are not bound automatically by default?

Also the reason much of this matters (and why I can't just update the methods defined on my types) is that I'm using ent to generate my model definitions.

versions

• gqlgen version? 0.13.0
• go version? 1.15
• dep or go modules? modules

[henrywoody]

Upon further thought, it now seems that even if the conditions for CorrectlyDoesNotMakeResolver are met (matching method on object type exists and takes all arguments defined by the resolver and schema and has correct return values) it may be nice to allow for the resolver to be generated anyway in case there's any additional handling that's required/desired in the resolver rather than on the model itself (which may serve in other non-API contexts).