But then the code to handle this in the generated API gateway is like:
func _DemoService_DoIt_APIGW_Decoder(ctx context.Context, input apigw_v1.DecoderInput, out proto.Message) error {
// some code before the buggy bit...
vn0 := input.Query().Get("thing")
if vn0 == "" {
vn0 = "0"
}
vn1tmp, err := strconv.ParseInt(vn0, 10, 64)
if err != nil {
return status.Error(codes.InvalidArgument, "thing is not a valid int: %s", err)
}
// some code after the buggy bit...
}
The temporary work around is to ignore/monkey patch the OpenAPI document to use the integer values instead, don't use query strings with enums, or monkey patch the generated decoded after generation. I'm opting for ignoring the OpenAPI and sending an integer for my project for now.
If time allows, I hope to see about coming back around here and putting together a PR in few days.
This problem shows up whenever you use an enum in a query parameter:
This will generate an OpenAPI spec that looks like:
But then the code to handle this in the generated API gateway is like:
The temporary work around is to ignore/monkey patch the OpenAPI document to use the integer values instead, don't use query strings with enums, or monkey patch the generated decoded after generation. I'm opting for ignoring the OpenAPI and sending an integer for my project for now.
If time allows, I hope to see about coming back around here and putting together a PR in few days.