Grpc-go: Broken Response After Adding New Param into Response Message

[iDevoid]

Example

Take a look of my example, let's say the logic of this example, if i sent numeric, it should return true with message "Number". and of course it returns error if gRPC failed.

Payload - no change

message ItsPayload{
    string InPayload = 4;
}

• older version of message

message Numbers{
    bool Correct = 1;
    string Message = 2;
}

• expected response:

payload: "1" ====> response : < Correct: True, Message: "Number" >
payload: "N" ====> response: < Correct: False, Message: "NOT Number" >

the client binary has been using this for days return perfectly fine.
Then, I made an update to gRPC Response Message

• new version of message

message Numbers{
    int64 TheNumber = 1; // will return ASCII from string, if NOT a number 
    bool Correct = 2;
    string Message = 3;
}

then, i try again to call it from client (no restarting binary), and the response message isn't the same again

• expected response:

payload: "1" ====> response : <  TheNumber: 1, Correct: True, Message: "Number" >
payload: "N" ====> response: < TheNumber: 78, Correct: False, Message: "NOT Number" >

• actual response from client:

payload: "1" ====> response : < Correct: False, Message: "NOT Number" >
payload: "N" ====> response: < Correct: True, Message: "Number" >

so, I tried to reproduce this case, clone the client code, tried to run, it got error grpc: failed to unmarshal the received message unexpected EOF.
the case is closed because i update with last commit of gRPC and dep ensure it again, with newer dependency, it now responses correctly

Question:

How come this actually happens? I mean, instead of getting _error_ with client(the binary i didn't restart before) it still returns the message, which is incorrect.
And it wasn't the same for code i just build, it return error.

[menghanl]

Changing field number in proto messages is API change. In fact, you should never do it: https://developers.google.com/protocol-buffers/docs/proto3#assigning-field-numbers

Having inconsistent field numbers can cause undefined behavior. The binary format for the new field might be a valid value for the old field, but with very different meanings.

gRPC versions shouldn't affect any of those.
If your proto library was also updated, it could have changed some behavior (that affects field number changes), but even that also seems rare to me.

By rebuilding your client, it picks up the new message definition. So the messages are now consistent, and things start to work again.