gqlgen: Not possible to discern GraphQL scalar unmarshal errors in error presenter
What happened?
Errors occurring in packaged scalars like Int return unstructured errors making them difficult to identify in an error presenter.
See https://github.com/99designs/gqlgen/blob/414a4d3414b2b5856851816f0152980098f7b3ab/graphql/int.go#L16-L29 for example.
In our case, we catch any top level errors that are not one of our expected types to ensure we don’t leak internal information to the API due to neglecting to wrap an error. However, I don’t see an easy way to catch these errors aside from implementing our own unmarshaling functions.
What did you expect?
I’m curious if it would make sense to return gqlerror.Errors in the Unmarshal* scalar methods so that an error presenter could identify that these errors are safe to pass back to the client.
Alternatively, perhaps they could return a new error type like gqlerror.UnmarshalError.
versions
- gqlversion 0.9.0
- go version 1.12.6
About this issue
- Original URL
- State: open
- Created 5 years ago
- Comments: 17
Any updates on this?
From what I’ve seen the most common behavior seems to be to hide all opaque error types (i.e. those created by errors.New or fmt.Errorf without the
%wflag), and present the error types that are known in order to not leak any implementation details.Or is there some other recommended strategy to go about this that I’m missing?
I’m happy to open a PR if this behavior would be welcome. I think it would be nice to have
gqlgenhandle this rather than defining our own wrapper implementations so that everyone can benefit.