I can't comment on the C# specifics, but when dealing with protobuf
changes, one should never reuse the ordinal numbers of deleted fields. If
you don't need a field anymore, you should *reserve* the field number. You
can find some documentation on this over here
<https://developers.google.com/protocol-buffers/docs/proto3#reserved>.
A better approach here for your version 2 would be:
message A {
reserved 2;
string field1 = 1;
map<string, int> field3 = 3*;*
}
This will avoid problems with coding/decoding the message, which I suspect
you are experiencing here.
Hope that helps,
Terry
On Thursday, October 13, 2022 at 11:07:12 AM UTC-7 sre.ag...@gmail.com
wrote:
> Hi All,
>
> I recently observed some behavior w.r.t proto message -
> marshalling/unmarshalling. Wanted to know if there is a better way to
> determine the contract break specifically for code written in C#?
>
> Client (Version 1) and server (Version 1) were using different versions of
> a message with some **breaking change**. My understanding **was** in case
> of a contract break we will see some sort of exception but turns out the
> field (*field3*) was just an empty object [*Not null*]. In our scenario
> it is possible to have an empty object for that field, so checking null or
> empty object won't help either.
>
> Is there a guideline to determine a contract break at run time? Or do we
> need to somehow ensure in our code change review process or build process
> that ordinals are not changed?
>
> *Version 1*
> Message A {
> string field1 = 1;
> uint64 filed2 = 2;
> map<string, int> field3 = 3;
> }
>
> *Version 2*
> Message A {
> string field1 = 1;
> map<string, int> field3 =* 2;*
> }
>
> Regards,
> Vivek
>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/e5faf6bd-0cc9-43cd-ad5a-c450b7a9f06bn%40googlegroups.com.
