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)

Most upvoted comments

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 a MarshalX 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.

func MarshalScalarType(t ScalarType) graphql.Marshaler {
	return graphql.WriterFunc(t.MarshalGQL)
}

func UnmarshalScalarType(v interface{}) (t ScalarType, err error) {
	err = t.UnmarshalGQL(v)
	return
}

For anyone looking for a temporary solution, doing something like this is enough to bypass it:

type ScalarType []string

func MarshalScalarType(t ScalarType) graphql.Marshaler {
	return graphql.WriterFunc(func(w io.Writer) {
		b, _ := json.Marshal(t)
		w.Write(b)
	})
}

func UnmarshaScalarType(v interface{}) (ScalarType, error) {
	value, ok := v.(ScalarType)
	if !ok {
		return nil, errors.New(fmt.Sprintf("Failed to unmarshal ScalarType: #%v", v))
	}
	return value, nil
}

Easily reproducible with a scalar like:

type ScalarType []string

func (s *ScalarType) UnmarshalGQL(v interface{}) error {
	s, ok := v.(*ScalarType)
	if !ok {
		return errors.New(fmt.Sprintf("Failed to unmarshal value: #%v", v))
	}
	return nil
}

func (s ScalarType) MarshalGQL(w io.Writer) {
	b, _ := json.Marshal(s)
	w.Write(b)
}

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{}