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?

CodePudding user response：

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