0000 1000 1101 0010

> Literally not a spec, this document starts with: > > > The metric and label conventions presented in this document are not required for using Prometheus, but can serve...

The Map type in both Protobuf and Go are defined, by their respective specifications, to be un-ordered. Even if you carefully encode a Protobuf Map `{a: 1, b: 2}` as...

> We care primarily about deterministic serialization of maps in consensus and that is a solvable problem. As long as transactions, and all other user-submitted and signable data, cannot contain...

> Note that I would see this as a small helper to enable folks to migrate to the OpenMetrics format eventually. OpenMetrics remains an experiment, not a standard. Prometheus client...

You definitely can't reset a counter to 0 arbitrarily :) A counter can only be incremented, it must never be decremented or set to an arbitrary value, resets to 0...

Interesting! Let me try to grok it...

It is effectively never appropriate to use an address as a label, for reasons of cardinality already discussed.

> when using multimsg currently if one message fails in the batch the complete tx is reverted. There is a valid use case of allowing the messages that succeed, succeed,...

```go return f, modify(&f) ``` Such code seems to me to be pretty clearly buggy, in a similar way to code that relied on map iteration order (prior to the...

Is sorting metrics in this way guaranteed by the spec?