-
Notifications
You must be signed in to change notification settings - Fork 490
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error if a resolver returns invalid enum value #262
Comments
right now golang does not have enums, so that if your server returns not available value then you handle enums values not as 'enums' really. syntax = "proto3";
option go_package = "resolver";
enum DayOfWeek {
// For copability with proto2
UNKNOWNDay = 0;
MONDAY = 1;
TUESDAY = 2;
WEDNESDAY = 3;
THURSDAY = 4;
FRIDAY = 5;
SATURDAY = 6;
SUNDAY = 7;
}
and then write methods for graphql //go:generate protoc --go_out=. enums.proto
func (x DayOfWeek) ImplementsGraphQLType(name string) bool { return name == "DayOfWeek" }
func (x DayOfWeek) MarshalJSON() ([]byte, error) { return []byte(x.String()), nil }
func (x *DayOfWeek) UnmarshalGraphQL(input interface{}) error {
p, ok := input.(string)
if !ok {
return fmt.Errorf("wrong type, expecting string")
}
v, ok := DayOfWeek_value[p]
if !ok {
return fmt.Errorf("unacceptable enum value %s", p)
}
*x = DayOfWeek(v)
return nil
} |
Thanks for the tip! I might use this! This doesn't solve my problem completely though. The problem exists even in this case. If you define a different set of enum values in your protobufs vs in the graphql schema, it's possible to return an invalid (based on the schema) result to the client. I would prefer this to be a caught as a server error because it's really the server's fault. |
I think, we can find plugin for protoc which generates graphql enums. |
also, this lib allows to bind enums not only to strings but ints or any other type you want |
@gracenoah is this causing problems for your applications? We've been using a lot of enums in our projects and we have never faced this problem so far. Isn't this something that you can catch with unit tests? Or is your data coming from an external system (e.g. a datastore or a service) which is unpredictable? |
Right now resolvers that return enums can return any string. This can cause issues for clients that expect the server to return one of a set of known values. It would be useful to have the resolver fail more quickly on the server side in this scenario instead of failing when the client interprets the response.
The text was updated successfully, but these errors were encountered: