Three ways our first chart was wrong before it shipped
The directory statistics page is computed once a day and shows a handful of panels about the servers we track. One panel has a chart, a single line: signed results per day, last 90 days. It is 320 by 32 units of SVG. It went through three rounds of automated review, across two pull requests, before it merged, and each round found a different way in which it was not telling the truth.
1. “Last 90 days” was “the most recent 90 rows”
The query behind the chart ordered the daily table by day, newest first, and took 90 rows. On the day it was written the table was a week old, so 90 rows and 90 days were the same thing. They stop being the same thing the first time the daily computation does not run. Skip a day and the window silently becomes 91 days; skip ten and it is 100.
The x axis made it worse. Points were placed at equal intervals by their index in the result, so a missing day would not appear as a gap. The line would step straight from the day before to the day after, as if nothing had been skipped.
The review comment called the label a false statement, and it was. The fix has three parts. The query now has a lower bound, day >= today − 89 days, with the clock injected so a test can pin it. The same cutoff is re-applied after the rows come back, as a second layer, because a test’s mocked client does not evaluate the query and a future change to the query could widen the window without any test noticing. And the x position of each point is now its offset in days from the first day of the window, so a missing day is a visible gap. It is never filled with a zero: a zero would be a claim that nothing was signed that day, and the truth is that we did not compute it.
The limit(90) is still there. With the lower bound in place it is a ceiling, not the definition.
2. A timestamp with no time zone
Another panel lists recent tool set changes with the minute they were observed. The helper that formats those minutes returns YYYY-MM-DD HH:MM and, by its own documented contract, does not append UTC: every existing caller supplied the suffix in its own copy. The new panel’s call was the one that did not. It rendered 2026-09-22 08:18, bare. A reader in UTC+8 reads that as their local morning and is eight hours off.
The change was one call site, appending UTC where the other three callers already did. Changing the helper instead would have been wrong: the three existing callers would then have printed UTC UTC. A new test asserts the suffix on every rendered minute in that panel, and its failure was demonstrated by exporting the commit before the fix and running the same test against it. Nothing here was ambiguous; the fix took minutes. The point is that the previous, correct decision to leave the suffix to callers had created a contract that a new caller could break silently, and a contract only exists if a test holds it.
3. The line did not sit over its labels
The SVG has a viewBox of 320 by 32 and a width of 100%. Below it, the date labels are laid out across the full width of the container. On a narrow screen the two agree. In a desktop container of about 1,120 pixels the browser keeps the SVG’s aspect ratio by default, draws the line at 320 pixels wide, centres it, and leaves the labels spanning the whole width. The first date label sat under empty space and the line’s first point was hundreds of pixels to its right.
The fix is two attributes: preserveAspectRatio="none" on the SVG so that the drawing stretches to the container, and vector-effect="non-scaling-stroke" on the path so that the stroke does not stretch with it into a horizontally smeared line. Because that diagnosis was reasoned from the attributes rather than seen, the reviewer’s condition was to measure it before pushing: render in an 1,120-pixel container and confirm that the SVG’s rendered width equals the container’s. It did.
What this adds up to
None of the three would have corrupted any data. The daily table, the signed results and the observed minutes were all correct; only their presentation was wrong, in three unrelated ways, in a component of a few hundred lines that had already passed its own tests. A chart is a claim about data, and claims get reviewed like any other sentence on the site. Each of the three fixes came with a test that fails on the code as it was, and the pull request’s line count went over our usual limit because of them, which is allowed when the extra lines are fixing a false statement.
Where the facts come from
All three findings and their fixes are in the pull request history of the statistics page and its review comments. The rendered-width measurement was made in a local browser harness at 1,120 pixels and attached to the completion report before the third push. The chart’s data, the daily table, is described on the statistics page itself with the computation time of the row it shows.