All good points. It's worth mentioning that this is exactly why protobuf doesn't by default fail when it gets a field it doesn't recognize (there might be a fla

All good points. It's worth mentioning that this is exactly why protobuf doesn't by default fail when it gets a field it doesn't recognize (there might be a flag to control strict validation, but there is a reason that "required" fields were taken out in proto3). From the source code: https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/unknown_field_set.h https://github.com/protocolbuffers/protobuf/blob/master/src/... // An UnknownFieldSet contains fields that were encountered while parsing a // message but were not defined by its type. Keeping track of these can be // useful, especially in that they may be written if the message is serialized // again without being cleared in between. This means that software which // simply receives messages and forwards them to other servers does not need // to be updated every time a new field is added to the message definition. A bit more detail: For those who don't work with protos, they're the thing that Google created to use instead of XML before JSON was a thing. To use them, you define a message schema consisting of fields, where every field has (1) a number that will uniquely identify that field in the message, (2) a type for the field, and (3) a name for the field. The protoc compiler then generates code that decodes and encodes that specific message type for you. Now think about what happens when a new field is added to that message type and the code is re-generated. That change is probably going to be in at least three different binaries (and it's often more): the client, the frontend, and the backend. There's no way to guarantee that every single client, frontend, and backend picks up that change at the same time - it has to go out incrementally. So if client v2 talks to frontend v1 and gets routed to backend v2, frontend v1 damn well better not crash if it sees a new field.