Align on query param type when dealing with enums in gRPC & grpc-gateway

[clevinson]

Currently we have different ways of handling enums as parameter values in gRPC / grpc-gateway queriers.

1) Enum params as ints

As identified in #8808 (see comment), queries to /cosmos/gov/v1beta1/proposals, takes a query parameters ProposalStatus (a protobuf enum) as an int. So in order to query for specific status, you would query like so: /cosmos/gov/v1beta1/proposals?proposal_status=1. See code here, and proto def below:

// QueryProposalsRequest is the request type for the Query/Proposals RPC method.
message QueryProposalsRequest {
  option (gogoproto.equal)           = false;
  option (gogoproto.goproto_getters) = false;

  // proposal_status defines the status of the proposals.
  ProposalStatus proposal_status = 1;

  // voter defines the voter address for the proposals.
  string voter = 2;

  // depositor defines the deposit addresses from the proposals.
  string depositor = 3;

  // pagination defines an optional pagination for the request.
  cosmos.base.query.v1beta1.PageRequest pagination = 4;
}

2) Enum params parsed from strings

On the other hand, when querying validators by BondStatus (via the endpoint /comsos/staking/v1beta1/validators), we actually expect a string equal to the enum's String() value. So in order to query for a specific bond status, you would query like so: `/cosmos/staking/v1beta1/validators?status=BOND_STATUS_BONDED See code here, or proto def below:

// QueryValidatorsRequest is request type for Query/Validators RPC method.
message QueryValidatorsRequest {
  // status enables to query for validators matching a given status.
  string status = 1;

  // pagination defines an optional pagination for the request.
  cosmos.base.query.v1beta1.PageRequest pagination = 2;
}

Question

We should pick either (1) or (2) and ensure that all grpc queriers adhere to the same standard expectation.

Thoughts on this @AmauryM @atheeshp, others?

[clevinson]

My general feeling is:

1 (enum / int): Poor UX for grpc-gateway, good UX for gRPC
2 (stringified enum): good UX for grpc-gateway, passable UX for gRPC

One question I have is if its possible to have different logic depending on if queries come through grpc-gateway vs grpc?

[amaury1093]

Why not allow both?

I'm pretty sure grpc-gateway allows for both. For gRPC, we cannot have both, because gRPC requests are typed.

[amaury1093]

BTW, the QueryValidatorsRequest message should be updated. It should be BondStatus status = 1;

We can try to make this change in a non-breaking way: add a new field, then add some logic to coerce the old string status (if set) into the new BondStatus.