Repository navigation
fix(reporter): pad fractional part to two digits in number formatting - #23
Conversation
format_us_as_ms, format_percentage, format_rps, and format_time built "whole.frac" strings from an unpadded 0-99 fraction, so values below 10 rendered wrong (e.g. 80us -> "0.8ms" instead of "0.08ms", 61.05s -> "61.5s"), making percentile tables look non-monotonic. Apply the same zero-padding format_double already used. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #23 +/- ##
==========================================
+ Coverage 63.59% 63.79% +0.19%
==========================================
Files 16 16
Lines 739 743 +4
==========================================
+ Hits 470 474 +4
Misses 269 269 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Summary
Fix a leading-zero display bug shared by four formatters in
src/lib/reporter/format.mbt.Each built its output by interpolating an unpadded 0–99 fraction,
so any fraction below 10 lost a digit:
80µs rendered as "0.8ms" instead of "0.08ms",
making percentile tables look non-monotonic (e.g. p90 "0.8ms" next to p95 "0.11ms").
Affected functions and examples (before → after):
format_us_as_ms: 80µs "0.8ms" → "0.08ms"format_percentage: 33.05% "33.5%" → "33.05%"format_rps: 8.05 "8.5" → "8.05"format_time: 61.05s "61.5s" → "61.05s"The fix pads the fraction to two digits, mirroring the pattern
format_doublealready used.Rounding/truncation behavior is unchanged.
Verification
moon test --target native264/264,moon test(wasm-gc) 195/195🤖 Generated with Claude Code