0

I have a golang based GRPC service defined with proto3

syntax = "proto3";

For a simple Response of a single bool filed if the value is false the whole message is serialized just as an empty (zero length) data payload. (as my suspect, treating false as a default one)

Same time a node's GRPC client built from the very same .proto definition interprets the value as an undefined. (while true one is pretty consistent)

Debugging the way server builds the response

data, err := encode(s.getCodec(stream.ContentSubtype()), msg)

I've noticed, stream.ContentSubtype() returns an empty string so that within s.getCodec it is falls back to encoding/proto.Name which is just proto. And it leads further encoding something over here

func marshalAppend(buf []byte, m Message, deterministic bool) ([]byte, error) {
    if m == nil {
        return nil, ErrNil
    }
    mi := MessageV2(m)
    nbuf, err := protoV2.MarshalOptions{
        Deterministic: deterministic,
        AllowPartial:  true,
    }.MarshalAppend(buf, mi)

Which looks like really protoV2 implementation.

So I don't know what is really the right question here

  • Should stream.ContentSubtype() be somehow controlled on a communication level and who's to be responsible for this (Client/Server)
  • Should any additional control steps/actions be followed while generating client/server source codes from the .proto definition. Doesn't .proto it self generalize the meta enough to output consistent sources?
  • Should/Cloud proto3 be really encoded successfully with protoV2 implementation?
  • What else could cause such inconsistent values treatment?
hypp erster
  • 139
  • 7
  • What you are seeing in go appears to [comply with the spec](https://developers.google.com/protocol-buffers/docs/proto3#default) "For bools, the default value is false.". Note that [`optional`](https://stackoverflow.com/a/62566052/11810946) is now supported in proto3 (and if specified would change things a bit). – Brits Jul 15 '22 at 03:21
  • @Brits, got it thanks. Still what is the way to guarantee the encoded stuff to be treated on a client side exactly the same way it was encoded? – hypp erster Jul 15 '22 at 13:15
  • This is most likely just a deserialization setting on the client. What protobuf implementation are you using on the client? – murgatroid99 Jul 15 '22 at 16:31
  • @murgatroid99 https://www.npmjs.com/package/protoc-gen-ts, and I will take a look on some alternatives now – hypp erster Jul 15 '22 at 18:15
  • Oh, I am not familiar with that one. You may have some luck filing an issue on that library's GitHub project. – murgatroid99 Jul 15 '22 at 18:18
  • 1
    [This issue](https://github.com/thesayyn/protoc-gen-ts/issues/107) in the `proto-gen-ts` repo discusses the problem. – Brits Jul 15 '22 at 19:40
  • @murgatroid99 maybe you can share some other useful implementations as an alternative to play with? – hypp erster Jul 15 '22 at 21:01
  • 1
    The `@grpc/proto-loader` and `grpc-tools` libraries are officially maintained by the gRPC maintainers. Note that the code generated by `grpc-tools` also depends on the `google-protobuf` library. – murgatroid99 Jul 15 '22 at 21:24

1 Answers1

0

Turned out this was nothing with misconfiguration but a matter of specific implementation.

Six days ago it was fixed within porto-gen-ts v0.8.5

Thanks @Brits for a lookup

hypp erster
  • 139
  • 7