Build Errors with v0.17.64

[QuinceyJames]

As of v0.17.64, running gqlgen generate causes a file to be generated called prelude.resolvers.go that includes build errors. If I roll back to v0.17.64 the file is not generated and the build is successful.

package resolvers

// This file will be automatically regenerated based on the schema, any resolver implementations
// will be copied through when generating and any unknown code will be moved to the end.
// Code generated by github.com/99designs/gqlgen version v0.17.64

import (
	"context"
	"fmt"
	"sales-bp-integration-api-gateway/schema/server"

	"github.com/99designs/gqlgen/graphql/introspection"
)

// IsDeprecated is the resolver for the isDeprecated field.
func (r *__InputValueResolver) IsDeprecated(ctx context.Context, obj *introspection.InputValue) (bool, error) {
	panic(fmt.Errorf("not implemented: IsDeprecated - isDeprecated"))
}

// DeprecationReason is the resolver for the deprecationReason field.
func (r *__InputValueResolver) DeprecationReason(ctx context.Context, obj *introspection.InputValue) (*string, error) {
	panic(fmt.Errorf("not implemented: DeprecationReason - deprecationReason"))
}

// IsOneOf is the resolver for the isOneOf field.
func (r *__TypeResolver) IsOneOf(ctx context.Context, obj *introspection.Type) (*bool, error) {
	panic(fmt.Errorf("not implemented: IsOneOf - isOneOf"))
}

// __InputValue returns server.__InputValueResolver implementation.
func (r *Resolver) __InputValue() server.__InputValueResolver { return &__InputValueResolver{r} }

// __Type returns server.__TypeResolver implementation.
func (r *Resolver) __Type() server.__TypeResolver { return &__TypeResolver{r} }

type __InputValueResolver struct{ *Resolver }
type __TypeResolver struct{ *Resolver }

The errors reported:

schema/resolvers/prelude.resolvers.go:31:42: undefined: server.__InputValueResolver
schema/resolvers/prelude.resolvers.go:34:36: undefined: server.__TypeResolver

[TheBeachMaster]

Whenever I run into prelude.* related errors , I always refer to this comment #227 (comment)

Check if that helps.

[keshav-dataco]

Any workaround or update on this issue?

[keshav-dataco]

Whenever I run into prelude.* related errors , I always refer to this comment #227 (comment)

Check if that helps.

tried it doesn't help

[StevenACoffman]

Hi! Is it possible for you to set up a public repository that demonstrates this or a similar issue so I can see what is going on?

[andrestielau]

Hi, I just had an error similar to this one.

In my case it was a version update from version 0.17.63 to 0.17.64, since the generated resolver has the same name as the interface if I don't change the name of the resolvers they cause a conflict

__InputValueResolver redeclared in this block (see details)compiler[DuplicateDecl](https://pkg.go.dev/golang.org/x/tools/internal/typesinternal#DuplicateDecl)
prelude.resolvers.go(35, 6):
type __InputValueResolver interface { // size=16 (0x10)
    IsDeprecated(ctx context.Context, obj *introspection.InputValue) (bool, error)
    DeprecationReason(ctx context.Context, obj *introspection.InputValue) (*string, error)
}

I tried to generate exec in a different package but it seems that, since __InputValueResolver and __TypeResolver start with __ they're not importable from a different package, that doesn't seem to work

name __InputValueResolver not exported by package genertedcompiler[UnexportedName](https://pkg.go.dev/golang.org/x/tools/internal/typesinternal#UnexportedName)
type __InputValueResolver interface {
    IsDeprecated(ctx context.Context, obj *introspection.InputValue) (bool, error)
    DeprecationReason(ctx context.Context, obj *introspection.InputValue) (*string, error)
}

I might be doing something wrong, but since we can change the name of the generated revolvers this isn't blocking for me, just wanted to add some info.

[StevenACoffman]

Thank you all, these are very valuable reports! Can you all please take a moment to run this and report back what it says:

gqlgen version

I might be doing something wrong

Even if you are, if more than one person is doing something wrong, then it's a sign that something should be improved so it is easier to do the right thing, harder to do the wrong thing, or at least the error message should be better at telling people what to do different!

My theory as to what might be happening to you all is that you are only partially upgraded.

In #3507 I had to make a change to gqlgen to avoid this exact problem.

There are really two gqlgen versions to worry about. There's gqlgen-the-library and gqlgen-the-codegen-binary-command-line-tool.

When you run go run github.com/99designs/gqlgen generate or go generate ./... which looks for your source code files lines like //go:generate go run github.com/99designs/gqlgen generate to do the same thing, it will the gqlgen version specified by your go.mod's version (or using Go 1.24's tools.go https://tip.golang.org/doc/go1.24#tools). If you run this in the context of your application and your application uses any of the gqlgen-the-library code like any of the graphql scalar types it will probably have a version, and hopefully that is 0.17.64 or newer.

However, if you have previously installed an older version of gqlgen as a binary command line tool by doing something like:

go install github.com/99designs/gqlgen@latest

and then when you are regenerating your resolvers using this older version of gqlgen, your resolvers would exhibit this exact behavior!

So... I think that's what's going on. Please let me know what you find out!

[andrestielau]

Thank you for the swift response!

For the two things I wrote about the problem seems to still happen in 0.17.66

I replaced the go run github.com/99designs/gqlgen generate with gqlgen generate after installing the latest version (0.17.66) and the same thing happened (either the generated resolvers conflict with the interface names or the interfaces are Unexported)

I think it would be useful if the interfaces didn't start with __, although I don't know why __ prefix was used in the first place so I don't know if this would make sense, but the interfaces wouldn't be available to implement (since they're not exportable) for projects that don't generate exec in the same package that they have the resolvers in, and it would be more consistent with the remaining Resolver interfaces if the __ prefix was removed

But given that I have a workaround at least this is not breaking

[demeralde]

I'm getting this error as well but I'm not sure why. It happened after I upgraded to Go 1.24 and [email protected].

It seems to have generated this code in prelude.resolvers.go (which is also a new generated file):

// __InputValue returns graph.__InputValueResolver implementation.
func (r *Resolver) __InputValue() graph.__InputValueResolver { return &__InputValueResolver{r} }

// __Type returns graph.__TypeResolver implementation.
func (r *Resolver) __Type() graph.__TypeResolver { return &__TypeResolver{r} }

And then the graph package exports this:

type __InputValueResolver interface {
	IsDeprecated(ctx context.Context, obj *introspection.InputValue) (bool, error)
	DeprecationReason(ctx context.Context, obj *introspection.InputValue) (*string, error)
}
type __TypeResolver interface {
	IsOneOf(ctx context.Context, obj *introspection.Type) (*bool, error)
}

However it's not able to be imported, which seems to be because of the __ prefix (if I remove this, it imports fine).

I've also tried go install github.com/99designs/[email protected] then gqlgen generate (instead of go run github.com/99designs/[email protected] generate) but that didn't work either.

[StevenACoffman]

If anyone can provide a public repository where I can reproduce their issue, I would love to take a look, but I'm really not able to reproduce this behavior, so I'm just guessing that it is a local environment issue of some sort, rather than a specific code issue.

[k3v3n]

I was able to reproduce the issue on my side. The error was that I was using go 1.24 to generate. Once I've set back go 1.23, I was able to generate back again. So as @StevenACoffman, this is env issue where you try to generate with version 1.24, most. probably.

[StevenACoffman]

@k3v3n I'm glad you seem to be able to temporarily work around your issue. If you can set up a public repository somewhere, I would still love to try to examine it, as when I use Go 1.24 in our testing matrix here and in other repositories, I can't reproduce this issue.

[alek-sys]

My theory as to what might be happening to you all is that you are only partially upgraded.

Thanks, that is spot on! I was getting the same error in prelude.resolver.go.

Go generate directive was set up as:
//go:generate go run github.com/99designs/[email protected] generate

But go.mod had:
github.com/99designs/gqlgen v0.17.46 (so .46 and .66 versions).

So I'm guessing the generator couldn't find types to bind to, and generated them instead. The fix was simply bump both go.mod and go:generate versions to .66.

P.S. Ironically the reason to upgrade for me is migration to Go 1.24 to use go tool to manage gqlgen which eliminates this problem of version mismatch altogether.