| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
floatToGoString reproduces Go's strconv.FormatFloat(f, 'g', -1, 64),
which pads a float's exponent to a minimum of two digits. The exponent
was formatted as 'e+0{dot - 1}', which hard-codes a single leading zero
and only produces the right width while dot - 1 is a single digit. Once
the exponent reaches two digits (values >= 1e10, whose repr is still
plain decimal) it over-pads, e.g. 1e10 became '1e+010' instead of Go's
'1e+10'. That affects any emitted sample value or le/quantile bucket
boundary at or above 1e10.
Use '{dot - 1:02d}' so the exponent is zero-padded to a minimum of two
digits and not beyond, matching Go.
Add tests/test_utils.py covering both the previously-correct single-digit
exponents and the two-digit exponents that regressed.
Signed-off-by: Sean Kim <skim8705@gmail.com>
|
Thanks! |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
floatToGoString is meant to mirror Go's strconv.FormatFloat(f, 'g', -1, 64), which pads the exponent to a minimum of two digits (1e+06, 1e+10, 1e+15). The current formatting hard-codes a single 0 in front of the exponent:
That is only correct while dot - 1 < 10. As soon as the exponent needs two digits, the literal 0 becomes a spurious third digit:
So any histogram/summary whose le/quantile boundary is at or above 1e10 serializes a bucket label that doesn't match the value Go/Prometheus would emit for the same float.
Fix: zero-pad the exponent to two digits rather than prepending a literal 0:
This keeps the existing two-digit padding for small exponents (1e+06) and drops the extra zero for large ones (1e+10).
Added tests/test_utils.py covering both the single-digit (still zero-padded) and two-digit (no leading zero) cases.