php-bug-catcher / bug-catcher / 37302472055

94%

push

github

fix(dashboard): a sparkline that is not red at the top and does not end on the floor

Both lines on a project card drew something that was not true, and the two
faults compounded: the shape was pinned to the ceiling in the alarm colour and
then fell off a cliff at the right edge.

The red was an accident of scaling. `SparkLineEntry::rebase()` is a plain
multiplication with no clamp, so a value above the maximum is handed a
coordinate outside the SVG and the browser clips the line flat along the top -
inside the last colour of the gradient. LogSparkLine set its maximum to
`treshold`, so forty errors against a threshold of five came out at y=200 on a
30px canvas, and so did a hundred and twenty: every project with real traffic
drew the same picture. PerfSparkLine never set a maximum at all, which is worse
than it sounds - the scale was then the window's own peak, so the slowest hour
of a service answering in 20ms was painted exactly as red as the slowest hour of
one taking two seconds. The colour carried no information.

The cliff was a disagreement about what the newest bucket is. `Precision` keyed
the data with `round()` and built the x axis with `round(now - n * interval)`,
while the SQL bucketed with `floor()`. Past the halfway mark of an interval the
whole axis shifted forward and the last slot was a bucket in the future that no
row could land in, drawn at the library's placeholder height of 1 - the floor.
Before the halfway mark it was the bucket still filling up, which dips for the
same reason. Which of the two you got depended on what minute you looked, and
that is also why LogSparkLineTest failed on the wall clock rather than on the
diff.

So: clamp before the library sees a number, and stop agreeing on timestamps.
SparkLineScale projects a value onto 0..100 and the renderer tells the library
that is its maximum, which makes the threshold the point where the ramp runs
out instead of the point where the line leaves the canvas. LogSparkLine's que... (continued)

58 of 58 new or added lines in 5 files covered. (100.0%)

3192 of 3394 relevant lines covered (94.05%)

21.13 hits per line