v0.13.0 crashes gqlgen

[jwatte]

What happened?

I was using v0.11.3 and gqlgen works fine.
Updating to v0.13.0, and now gqlgen crashes.

What did you expect?

I expected v0.13.0 to still handle my schema.graphql, or at least to generate a meaningful error message.

Minimal graphql.schema and models to reproduce

$ 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
$

Haven't yet managed to distill it down to a small gqlgen case.

versions

• gqlgen version?
  v0.13.0

• go version?
  go 1.14.2

• dep or go modules?
  go modules

[omaskery]

Hi, I'm new to gqlgen, but I'm also getting this symptom. It occurred for me immediately after adding a custom scalar type:

1. I had defined, in my schema, a scalar ByteArray. Running gqlgen generate at this point runs successfully, but seems to default to using string types wherever ByteArray should be.
2. In my Go code I then implemented type ByteArray []byte and associated (un)marshaling methods.
3. In my gqlgen.yml I mapped my Go code to the scalar type:

   models:
    ByteArray:
        model:
          - github.com/me/my-project/path/to/model.ByteArray

4. When I next run gqlgen generate it fails with the same error as you:

   generating core failed: type.gotpl: template: type.gotpl:49:28: executing "type.gotpl" at <$type.Elem.GO>: nil pointer evaluating *config.TypeReference.GO
   

I am able to recreate this issue with the following schema:

schema {
    query: TestQuery
}

type TestQuery {
    test: ByteArray
}

scalar ByteArray

We appear to be triggering the issue in this part of the template:

gqlgen/codegen/type.gotpl

Line 49 in 997da42

var res = new({{ $type.Elem.GO | ref }})

[omaskery]

I'm stumbling in the dark a little here, I'm not used to this codebase, but from some digging:

The root of the issue seems like it's to do with how the codegen/config/binder.go TypeReference type handles named type definitions of slices?

When you have type ByteArray []byte, the TypeReference type:

• considers this nilable because its underlying type is nilable ✔️
• does not consider it a slice, even though the underlying type is a slice (I think this is correct?) ✔️

This means that in codegen/type.gotpl it ends up trying to call the unmarshaler, but it first must allocate a temporary variable to unmarshal into. In doing so it decides that, as a nilable type, it must use new. It seems to assume that if a type is nilable then you want to call new using the Elem() value, e.g. for *T it will allocate a new T:

gqlgen/codegen/type.gotpl

Line 49 in 997da42

var res = new({{ $type.Elem.GO | ref }})

Unfortunately, in the case of named type definitions, the Elem() function returns nil, as it itself is not a pointer or slice:

gqlgen/codegen/config/binder.go

Lines 177 to 204 in 997da42

	func (ref *TypeReference) Elem() *TypeReference {
	if p, isPtr := ref.GO.(*types.Pointer); isPtr {
	return &TypeReference{
	GO: p.Elem(),
	Target: ref.Target,
	GQL: ref.GQL,
	CastType: ref.CastType,
	Definition: ref.Definition,
	Unmarshaler: ref.Unmarshaler,
	Marshaler: ref.Marshaler,
	IsMarshaler: ref.IsMarshaler,
	}
	}
	if ref.IsSlice() {
	return &TypeReference{
	GO: ref.GO.(*types.Slice).Elem(),
	Target: ref.Target,
	GQL: ref.GQL.Elem,
	CastType: ref.CastType,
	Definition: ref.Definition,
	Unmarshaler: ref.Unmarshaler,
	Marshaler: ref.Marshaler,
	IsMarshaler: ref.IsMarshaler,
	}
	}
	return nil
	}

Judging by the type.gotpl file, it seems correct that it doesn't generate the code for deserialising a slice (as I don't know whether you can cast string to []interface{}, and even if you can it'd be a roundabout solution). As a result: that suggests that the fix needs to be something to do with how we choose the type we pass to new()?

Not sure what the best course of action is :)

[omaskery]

For reference, you can work around this issue for now by wrapping the byte slice (in this example) in a struct:

type ByteArray struct {
	Value []byte
}

// UnmarshalGQL implements the graphql.Unmarshaler interface
func (b *ByteArray) UnmarshalGQL(v interface{}) error {
	str, ok := v.(string)
	if !ok {
		return fmt.Errorf("ByteArray must be a string")
	}

	arr, err := base64.StdEncoding.DecodeString(str)
	if err != nil {
		return fmt.Errorf("ByteArray must be valid base64: %w", err)
	}

	b.Value = arr

	return nil
}

// MarshalGQL implements the graphql.Marshaler interface
func (b ByteArray) MarshalGQL(w io.Writer) {
	jsonStr := fmt.Sprintf(`"%s"`, base64.StdEncoding.EncodeToString(b.Value))
	_, _ = w.Write([]byte(jsonStr))
}

It's not ideal but only a minor inconvenience :)

[ThanhPhanTiki]

same problem

[adampresley]

I too am having the same issue with a custom type that is a slice of string.

[dball]

I seem to be having this issue with models I'm choosing to define as maps as documented here: https://gqlgen.com/reference/changesets/