When properties of an object are empty, empty buffer is returned from encode()

[scottburch]

I am not a protobuf expert. I am using someone elses .proto files and talking to a fixed service.

When I generate a message with no properties, or properties are empty, there is a check in the output that does not generate anything during encode.

This results in nothing being sent back to the other side. Is there a flag to remove this check? Or, am I missing some option?

Thanks

Examples:

message ResponseFlush {}

generates

  encode(_: ResponseFlush, writer: _m0.Writer = _m0.Writer.create()): _m0.Writer {
    return writer;
  },

message ResponseEcho {
  string message = 1;
}

generates

  encode(message: ResponseEcho, writer: _m0.Writer = _m0.Writer.create()): _m0.Writer {
    if (message.message !== "") {                                  // This is the problem, since the message is an empty string
      writer.uint32(10).string(message.message);
    }
    return writer;
  },

[stephenh]

Hi @scottburch ; afaiu this is correct/spec behavior.

Because both sides (client/server) of protobuf are expected to have the same schema, the wire format skips sending unset fields, to the point where a message field "with no set fields" itself is fully omitted, and the reader infers "the message is empty" from the lack of any bytes.

Granted, for ts-proto itself, this means fields like author.address (where address is an message Address) will be undefined, vs. other protobuf libraries/languages that will set author.address = {} ... I believe #1064 is the issue tracking this feature of "default instances".

Happy to have you correct my understanding/link to the docs/specs, but for now I believe this is working as intended. Thanks!

[scottburch]

Thank you so much for your response. I appreciate it. The behavior does not make sense to me since I can't send that message with an empty string, but I am NOT a protobuf expert. Anyway, I found that this message is actually sent as a subfield of another message, so it works.

Thanks again for the response.