Gqlgen: v0.12.1 crashes inside gotpl where v0.11.3 gives error messages

[jwatte]

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

[tsaikd]

I faced the issue when upgrading to v0.12.2 from v0.11.3. I guess it's a bug that assume Nilable Marshaler will have Elem at the same time. The following patch can work around, but I',m not sure any other edge cases will happen.

                {{- else if eq ($type.GO | ref) "map[string]interface{}" }}
                    return v.(map[string]interface{}), nil
                {{- else if $type.IsMarshaler }}
-                   {{- if $type.IsNilable }}
+                   {{- if and $type.IsNilable $type.Elem }}
                        var res = new({{ $type.Elem.GO | ref }})
                    {{- else}}
                        var res {{ $type.GO | ref }}
                    {{- end }}
                    err := res.UnmarshalGQL(v)
                    return res, graphql.WrapErrorWithInputPath(ctx, err)

[tmc]

For what it's worth this was introduced in 997efd0395b8d51312cc73f709a7545c928709a0

[jwatte]

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.

[fredbi]

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.