gqlgen: v0.12.1 crashes inside gotpl where v0.11.3 gives error messages
I’m running gqlgen on a schema that has some errors. v0.12.1 gives a very unhelpful error message:
[21:20:52] dev@devenv-55d5ff879f-9blcj:~/observe/code/go/src/observe/meta/metagql$ go generate
generating core failed: type.gotpl: template: type.gotpl:49:28: executing "type.gotpl" at <$type.Elem.GO>: nil pointer evaluating *config.TypeReference.GOexit status 1
resolver.go:1: running "go": exit status 1
[gqlgen-crash.zip](https://github.com/99designs/gqlgen/files/5086900/gqlgen-crash.zip)
v0.11.3 is more helpful:
[21:26:17] dev@devenv-55d5ff879f-9blcj:~/observe/code/go/src/observe/meta/metagql$ go generate
validation failed: packages.Load: /home/dev/observe/code/go/src/observe/meta/metagql/gql_dataset.go:700:33: cannot use ret (variable of type []*metatypes.Dataset) as *metatypes.Dataset value in argument to updateDatasetNilsToEmptyArrays
/home/dev/observe/code/go/src/observe/meta/metagql/progressive.go:443:24: cannot use results (variable of type []*metaparser.TaskResult) as []metaparser.TaskResult value in argument to canSendResults
/home/dev/observe/code/go/src/observe/meta/metagql/progressive.go:493:23: cannot use results (variable of type []*metaparser.TaskResult) as []metaparser.TaskResult value in argument to canSendResults
/home/dev/observe/code/go/src/observe/meta/metagql/progressive.go:517:21: cannot use results (variable of type []*metaparser.TaskResult) as []metaparser.TaskResult value in argument to canSendResults
exit status 1
resolver.go:1: running "go": exit status 1
I expect gqlgen to not crash with an error message that tells me nothing about where the cause for the error is, instead I expect it to give me good error messages.
(I think 0.11.3 actually generated the code and the errors come from the go compile command, so maybe this reduces to “v0.12.1 shouldn’t crash, period!”)
Attaching schema.graphql and gqlgen.yml files
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 6
- Comments: 15 (2 by maintainers)
With 0.12.2, we now crash even on seemingly legitimate schemas (that work well in 11.3) so we have to pin version 11.3. Unfortunately not easy to extract into a simple reproduction case, as we have a large gqlgen.yml that maps the API to our internal business entities in a bunch of different packages.
I just noticed #1317 was merged in 3 days ago so I updated to gqlgen@master and this is resolved (for me at least). I was having the same issue as @jwatte but now everything works with custom MarshalGQL/UnmarshalGQL methods on the ScalarType.
@minitauros It’s working around the problem by replacing the
MarshalGQL
method with aMarshalX
function. This is templated differently, so it avoid the problem code-path.It appears GQLGen gives preference to the function format, so you can simply call the original method as a work-around, and remove it when this bug is fixed.
For anyone looking for a temporary solution, doing something like this is enough to bypass it:
Easily reproducible with a scalar like:
Are there any plans to fix this in the near future?
I’ve had a similar issue that prevents me from upgrading from v0.11.3. I described it in #1391, but I cannot tell if this is really a duplicate issue. I’ve posted a PR to work around my problem (#1392), which is due to external scalar types of the
map
kind.We tried the fix proposed by @oiime and @duckbrain above and it didn’t work. There has been a PR up for this for quite a while (see #1317); I have poked one of the maintainers to see if it can be merged sooner rather than later.
Running into the same problem with a
map[string]interface{}
(which we use for JSON types).v0.13.0
I think fredbi’s problem is the same as mine – I also have a scalar type that’s map[string]interface{}