Enums are not handled correctly in queries

[zostay]

This problem shows up whenever you use an enum in a query parameter:

enum Thing {
    THING_UNSPECIFIED = 0,
    THING_ONE = 1,
    THING_TWO = 2
}

message DoItRequest {
    Thing thing = 1;
}

message DoItResponse {}

service DemoService {
    rpc DoIt(DoItRequest) returns (DoItResponse) {
        option (apigw.v1.method).operations = {
            method: "GET",
            route: "/doit",
            query: [
                {
                    key: "thing",
                    value: "thing",
                }
            ];
        };
    }
}

This will generate an OpenAPI spec that looks like:

/doit:
  get:
    parameters:
      - in: query
        name: thing
        schema:
           description: The thing field.
           enum:
             - THING_UNSPECIFIED
             - THING_ONE
             - THING_TWO
           readOnly: false
           type: string

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.

[pquerna]

Yeah, makes sense. I think generally we should probably support ingesting either the Int or the Enum Strnig [like protojson does].