Enums in proto files fail.

[maurogonzalez]

Testing enum types in proto messages I got the following errors:

https://github.com/maurogonzalez/rpctest/tree/enums

Using protocol.proto
And srcGen to generate scala code.

• grpc client returns:

ERROR:
  Code: Internal
  Message: grpc: failed to unmarshal the received message type_enum field HelloResponse.message is not compatible with nil value

• mu client logs:

// ClientApp
 ...
client.sayHello(Test.HELLO)

// Server Log: INFO GreeterServiceHandler - Request: HelloRequest(GOODBYE)
// Client Log: INFO GreeterServiceClient - Request: HELLO - Result: HelloResponse(GOODBYE)

• Not sure if it is related with Scala objects and Java's io.grpc.

[toddburnside]

@maurogonzalez, could you clarify where you are seeing this error? It looks like the mu client is succeeding. I also successfully tested the mu client with your code.

Are you seeing the error in your go client? Or elsewhere?

[maurogonzalez]

@toddburnside Sorry for the late response. I didn't update the README but to get the behavior:

• Run the ServerApp (https://github.com/maurogonzalez/rpctest/blob/enums/modules/rpctest/app/src/main/scala/rpctest/ServerApp.scala)
• Run the ClientApp (https://github.com/maurogonzalez/rpctest/blob/enums/modules/rpctest/app/src/main/scala/rpctest/ClientApp.scala)

Current behavior:

• Client sends HELLO in the message
• Server receives GOODBYE message. The expected behavior is to receive the HELLO enum (https://github.com/maurogonzalez/rpctest/blob/enums/modules/rpctest/app/src/main/resources/protocol.proto#L17)

[toddburnside]

@maurogonzalez OK, I see what you mean, now. It appears that no matter what the client sends to the server, the server sees GOODBYE. Not very friendly behavior on the part of the server. 😬

[toddburnside]

It turns out the server is also seeing the first enum in alphabetic order. So, if you have enum values of ACK, CHECK and 'QUACK, the server will always see ACK` no matter which order they are defined in the enum. I'll keep looking into this.

[maurogonzalez]

I haven't had much time to investigate deeply, sorry.

Thanks @toddburnside !

[toddburnside]

I did some more investigating. It turns out PBDirect doesn't work properly with the code generated for the enums.

Given this definition in the .proto file:

enum Test {
  LATER = 0;
  HELLO = 1;
  GOODBYE = 2;
  HI = 5;
}

The following scala code is generated:

sealed trait Test
object Test {
  case object LATER extends Test
  case object HELLO extends Test
  case object GOODBYE extends Test
  case object HI extends Test
}

Although PBDirect has code for handling coproducts via shapeless, and doesn't complain about this encoding, it appears to always send an empty field over the wire for them. I'm uncertain why this results in them being deserialized into the cast object with the smallest value in alphabetic order (GOODBYE in this case), but that is what is happening.

Looking at the tests for enums in PBDirect here, it appears that PBDirect uses some extra traits when encoding protobuf enums. If I change the scala code to the following, everything works as expected.

sealed trait Test extends Pos
object Test {
  case object LATER extends Test with Pos._0
  case object HELLO extends Test with Pos._1
  case object GOODBYE extends Test with Pos._2
  case object HI extends Test with Pos._5
}

I think that extending Pos, Pos._0, etc. is required in order to support the fact that protobuf assigns integral values to enum members, and that those numbers do not need to be contiguous. So, it seems like in order to allow the use of enums with protobuf, our generated code will need to include the above.

Anyone have any thoughts on this?

[toddburnside]

higherkindness/skeuomorph#100 was created to continue discussion on this issue.

[dzanot]

It's worth noting that #606 depends on us being able to pick the "Zero" element for enum defaults. Per the protobuf docs:

every enum definition must contain a constant that maps to zero as its first element. This is because:

There must be a zero value, so that we can use 0 as a numeric default value.

[cb372]

This issue should be fixed in the latest version (v0.20.1) of mu-scala. We've largely rewritten the protobuf serialization library and fixed a lot of bugs, as well as improving support for protobuf enums. The mu-scala codegen will now encode enums in Scala as enumeratum IntEnumEntrys, meaning the serialization library can serialize them to protobuf with the correct ordinal.

If you have any more problems with enums, please open a new issue.