This should be optional, but this deprecated library gogo-protobuf does not support optional fields 🙃

There are lots of optional fields in the examples, e.g. https://github.com/gogo/protobuf/blob/f67b8970b736e53dbd7d0a27146c8f1ac52f74e5/test/example/example.proto#L50

That's not a gogo vs. official protobuf problem, it's a proto2 vs proto3 problem.

proto3 doesn't distinguish between optional and required.

When removing the optional, this is the error I get in CI:

io/prometheus/client/metrics.proto: is a proto3 file that contains optional fields, but code generator protoc-gen-gogofast hasn't been updated to support optional fields in proto3. Please ask the owner of this code generator to support proto3 optional.--gogofast_out: 

Does

      google.protobuf.Timestamp  created_timestamp = 3  [(gogoproto.nullable) = true];

Work?

Neat. Would that maybe even help with this issue?

In different news: Note that essentially everything is (formally) optional in the proto2 definition. And all of these fields are now "normal" proto3 fields. Same can be done for the created_timestamp. The problem is that then we cannot distinguish between "unset" and "set to default value", but maybe the suggested [(gogoproto.nullable) = true] helps with that.

About the possibility to set optional at all: I'm surprised that this is possible now (again). Here's the original rationale for not allowing optional: protocolbuffers/protobuf#2497 (which is the same rational why all non-repeated fields are marked optional in proto2).

Apparently, optional was brought back in protobuf v3.15, with the aim to enable detection if a field was unset, which [(gogoproto.nullable) = true] should also allow. So I guess we'll go with the latter, and once we move on from gogoproto to another protobuf implementation (that is actually maintained), we can change this to optional.

Noice, I wasn't aware that we could work around this way :)

Thanks for the suggestion!

Thanks everybody for helping!

Should it go on Metric rather than on the individual sub-components?
And be an int64 like timestamp_ms?

I'm basically copying what was already merged in client_model. Unfortunately the proto is duplicated in this repo 😕

Yeah, this is indeed just a port to proto3 from client_model. (And FTR, since created_timestamp only exists for some metric types, it would be a mistake to put in on Metric.)

Let's add empty line back (just convention)

Let's add empty line back (just convention)

I'm surprised that the linter allowed this 🤔