proto: Problem differentiating not-set value from default value

Problem

The OpenMetrics Protobuf specification is using the proto3 syntax.

With the proto3 syntax all fields are optional by default. This is not to be confused with null-able. While one can choose not to specify a field it is then represented by its default value. Someone receiving a proto3 encoded payload has no way to tell the difference between a field explicitly set to its default value or not set at all.

The most prominent case where this can be problematic is for boolean fields where both the default value and the not-set value is false. In the context of OpenMetrics, as far as I can tell, one problematic example would be the examplar field in the CounterValue message. A use can not tell the difference between a not-set examplar and an examplar set to 0.

https://github.com/OpenObservability/OpenMetrics/blob/1ff04f252cec929acd9a569fce87b8ec4f72b086/proto/openmetrics_data_model.proto#L109-L123

Solution

To solve the above I see 3 solutions:

1. The optional keyword, which would allow differentiating between a default value and a not-set value, was initially removed with the proto3 syntax, but has been revived with v3.12.0. In case requiring protoc v3.12.0 is fine, one could just make use of the revived optional keyword.
2. The optional keyword is just syntactic sugar for oneof. Thus, in case requiring protoc v3.12.0 is not an option, one can use oneof directly. See this stackoverflow answer.
3. Use proto2 instead of proto3 (see original Prometheus proto definition).

Further reading

• General Stackoverflow discussing optional in proto3.
• Protoc release introducing optional to proto3.
• Documentation on field presence.

What do people think? Do you see alternative approaches?

Given that I don't have much expertise with Protobuf I might be missing something. If so, I would appreciate an answer pointing out my mistake.

Start with proto/openmetrics_data_model.proto around lines 109-123 and review the linked OpenMetrics Protobuf specification. Compare the referenced Prometheus metrics.proto definition and the three proposed approaches, then establish which field-presence behavior the schema should support and how completion would be verified.