tl;dr: We should prevent extrapolation below zero in rate and increase calculations, in a similar way as for simple float counters.

TODOs are in the code and in the spec.

By not doing it, we sometimes get different results from a NH vs. a simple float counter counting the same thing, e.g. there is a NH request_duration_seconds and a counter requests_total, the former observing the request duration and the latter just counting the requests. Ideally rate(requests_total[5m]) and histogram_count(rate(request_duration_seconds[5m])) will yield precisely the same result. However, due to not blocking extrapolation below zero, the rate calculated through NHs can be higher.

Similarly, if we scrape a classic histogram as NHCB, we ideally want precisely the same result from the NHCB as from a classic histogram that was ingested as such.

The subtleties (or why we cannot have nice things):

The fundamental problem is where to limit the extrapolation. A NH has count and sum and many buckets all in the same metric. The intersection with the zero point may be at different times for each of those. I would assume we should use the same cut-off time for the whole NH, so maybe the most recent one? However, in this way, we cannot perfectly emulate the behavior with simple float counters (because those only look at the count) and with classic histograms (because those would happily pick a different cut-off point for each bucket and the count and the sum) – unless of course we are happy with taking different cut-off points for each (which feels terribly inconsistent from the pure NH perspective).

The silver lining: If we have a perfect zero sample in the game (where count and sum are both zero and all buckets unpopulated), there is no discrepancy: The time of that zero sample is the cut-off point. In particular when utilizing synthetic zero samples inserted via the created-timestamp, we have that happy scenario and can do the nice thing after all.