Incorrect enum unmarshalling for zero values

[a7emenov]

Version of mu: 0.23.0
Used dependencies: mu-rpc-service, mu-rpc-server.
Description:

Clients generated by mu appear to incorrectly unmarshal enum values that are assigned to 0. More specifically, such values will be interpreted as None by the client, making it impossible to distinguish them from unknown or invalid values. However, servers seem to behave as expected.

Example:

• Proto file:

syntax = "proto3";

package example;

option java_package="example";

message HelloRequest {
    ExampleEnum value = 1;
}

message HelloResponse {
    ExampleEnum value = 1;
}

service Greeter {
    rpc SayHello (HelloRequest) returns (HelloResponse);
}

enum ExampleEnum {
    Option1 = 0;
    Option2 = 1;
}

• Server code:

import cats.effect.{ExitCode, IO, IOApp}
import example.hello._
import higherkindness.mu.rpc.server.{AddService, GrpcServer}

object TestApp extends IOApp {

  implicit val greeter: Greeter[IO] = new Greeter[IO] {
    override def SayHello(req: HelloRequest): IO[HelloResponse] = {
      IO.delay(println(req.value)) *>
      IO.pure(HelloResponse(Some(ExampleEnum.Option1)))
    }
  }

  def run(args: List[String]): IO[ExitCode] = for {
    serviceDef <- Greeter.bindService[IO]
    server     <- GrpcServer.default[IO](8081, List(AddService(serviceDef)))
    _          <- GrpcServer.server[IO](server
  } yield ExitCode.Success

}

• Client code:

import cats.effect.{ExitCode, IO, IOApp, Resource}
import example.hello._
import higherkindness.mu.rpc.{ChannelFor, ChannelForAddress}

object TestClient extends IOApp {

  val channelFor: ChannelFor = ChannelForAddress("localhost", 8081)  // 1

  val clientResource: Resource[IO, Greeter[IO]] = Greeter.client[IO](channelFor)  // 2

  def run(args: List[String]): IO[ExitCode] =
    for {
      response <- clientResource.use(c => c.SayHello(HelloRequest(Some(ExampleEnum.Option1))))  // 3
      _        <- IO.delay(println(response.value))
    } yield ExitCode.Success
}

• Scenarios (3-rd party RPC client link):

  • Sending a request to the server with the "value" field equal to 0 (TestEnum.Option1).
    Result via BloomRPC: server correctly logs "Some(Option1)", client correctly interprets Option1 in the response.
    Result via a mu client: server correctly logs "Some(Option1), client incorrectly logs "None" (expected "Some(Option1)")

  • Sending a request to the server with the "value" field equal to 1 (TestEnum.Option2).
    Result via BloomRPC: server correctly logs "Some(Option2)", client correctly interprets Option1 in the response.

  • Sending a request to the server with the "value" field equal to 2 (invalid enum value).
    Result via BloomRPC: server correctly logs "None", client correctly interprets Option1 in the response.

Changing TestEnum.Option1 to TestEnum.Option2 in the first scenario makes it behave as expected, so this issue only affects enum values assigned to 0.

[a7emenov]

Providing a custom reader via PBScalarValueReader yielded no result. It receives zero just fine and transforms it to the correct enum value, but the end result is still None for some reason.

[a7emenov]

Providing a custom PBFieldReader[Option[ExampleEnum]] seems to do the trick, so there's at least a workaround. One can place it in a package object in the same package which contains generated sources.