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
stream.ContentSubtype()
be somehow controlled on a communication level and who's to be responsible for this (Client/Server).proto
definition. Doesn't .proto
it self generalize the meta enough to output consistent sources?proto3
be really encoded successfully with protoV2
implementation?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