Is there a change in schema compatibility rules for optional complex types?

[rahulgulati89]

Hi,

We are trying to upgrade from buf 1.11 to buf 1.32 and found that the comatibility rules and their return codes have changed for some scenarios when we go from older version to newer version.

Lets say we have the following proto schema which uses a another schema as a reference.

syntax = "proto3";

package optionals.v1;

import "optionals/v1/reference.proto";

option csharp_namespace = "Optionals.v1";

// A documentation entry.
message OptionalMessage {   
   // A doc entry
   optionals.v1.ReferenceMessage reference_field = 1;
}

When i try to make the field as an optional like below, then buf 1.32 does not break the compatibility and gives output with 0 return code. However if i stay on 1.11 then it treats this change as a breaking change and gives the output with return code as 100.

syntax = "proto3";

package optionals.v1;

import "optionals/v1/reference.proto";

option csharp_namespace = "Optionals.v1";

// A documentation entry.
message OptionalMessage {   
   // A doc entry
   **optional** optionals.v1.ReferenceMessage reference_field = 1;
}

Similarly, If I change the optional field back to non optional then also newer version of buf does not complain.

[emcfarlane]

For proto3 files the optional modifier has no affect on the cardinality of the message. A proto3 message already has explicit presence. In versions of buf less than v1.32 the following annotation error was reported:

b/optionals/v1/other.proto:12:3:Field "1" on message "OptionalMessage" moved from outside to inside a oneof.

This was for the rule FIELD_SAME_ONEOF which has now been corrected in versions equal and greater than v1.32.

Commenting here to close off the discussion from slack, we are adding some more documentation to make the field presence issue more clear. Thanks!