Default field protection / detect missing request fields from consumer

[mefellows]

In protobufs, there are no longer such things as required fields (since proto 3). This means any server that has new fields on the request side of an interaction can be communicated to from old clients - the required fields will have default values inserted in their place.

This can result in nefarious bugs however. For example, if you have a new field enablePayments on an API request the client doesn't know about, it will be set to false each time the client makes the call. This could result in strange behaviour, where a call to update a profile is all of a sudden causing strange side effects such as preventing payment disbursements (this is a real live use case obtained from a global payments provider).

This scenario could potentially be solved in a few ways. One analogy I can think of is to - in addition to the consumer contract check - perform a schema check with a similar behaviour to OAS's additionalProperties. It would compare the consumer/provider protobuf definitions, and check for the presence of additional request fields on the provider side.

If there are additional unknown properties, the plugin could be configured to fail.

[TimothyJones]

Would failing on additional unknown properties just bring back required fields?

[mefellows]

Would failing on additional unknown properties just bring back required fields?

Yes, it effectively makes all request fields required. Consumers of course would be free to set a default value, but at least they'd be making a conscious choice. If we were to go that approach, it would likely be an opt-in.