0

We have decided to upgrade to proto3 but will still have to be able to communicate with devices running proto2 for a while.

Now we are facing some problems with some messages that they cannot be deserialized on the proto2 side due to the required keyword.

This is one message we have problem with (proto2).

message time_value
{
    required uint32 hour         = 1;
    required uint32 minutes      = 2;    
    required uint32 microseconds = 3;
}

If we try to send this message to a proto2 client and has set values like following hour=1, minutes=2, microseconds=0 then the client cannot deserialize this message. Setting microseconds=1 then the proto2 client has no problem reading the message.

This boils down to the following generated C# code 

public void WriteTo(pb::CodedOutputStream output) {
...
      if (Microseconds != 0) {
        output.WriteRawTag(48);
        output.WriteUInt32(1);
      }
...
}

So it seems like the generated proto3 code does not send any fields if the field has the same value as the default value for the data type. This does of course make proto2 upset and does not want to deserialize the message because the field is marked as required but no value was received.

Is it possible to force the protoc to generate code that always send all the fields (even though they have the default value set) or can it be solved in some other way?

Thanks

Mikael Halvarsson
  • 1
  • As background - [Why required and optional is removed in Protocol Buffers 3](https://stackoverflow.com/questions/31801257/why-required-and-optional-is-removed-in-protocol-buffers-3) – stuartd Sep 13 '19 at 13:37
  • Does "recompile the proto2 end of the service with everything as 'optional'" count? – Marc Gravell Sep 13 '19 at 19:33
  • In the long run the proto2 end will also be replaced with proto3 on all devices. But for some extent period of time there will be devices running proto2 in it's current form that can not be upgraded or changed. – Mikael Halvarsson Sep 16 '19 at 06:59

0 Answers0