php-bug-catcher / bug-catcher / 37310158581

94%

Build Type

push

github

Committed by tito10047

Commit Message

feat(perf): a window you can point at, and a way in from the regression

`/performance` took no query parameters at all, so the only view it could offer
was the last N hours of everything - which is the one view that cannot answer
what a regression asks. The window also lived three times over as an
unsynchronised `int $hours`, and `PerfReportBuilder::timeSeries()` has taken a
`$path` since it was written with nothing ever passing one.

The window is now `(at, hours)`: `[at, at + hours)`, with no `at` meaning "ends
now", byte for byte what every panel did before. `PerfRangeResolver` is the only
thing between the query string and a chart and owns both hardenings - `hours` is
clamped to `[1, MAX_HOURS]` (a year, the last window that is still a chart at 365
day-points; without a ceiling `?hours=100000` is a denial of service anybody can
type against a page that is often behind no firewall), and an `at` that does not
parse falls back to live rather than throwing. Strict parsing on purpose: `now`
and `+3 weeks` would make a link's window depend on when it was clicked.

Each panel keeps its own copies, the way each already keeps its own `sort` and
`group`; the URL seeds the first render. Granularity stays out of the controls -
`GranularityResolver` picks it from the width and the x labels already self-thin.

`Detail:PerfChart` closes the loop with a link carrying `at` half a window *before*
`windowAt`, so the spike lands in the middle, plus the route and a
`#perf-path-<md5>` fragment the matching `PerfTopPaths` row answers to. Centring
is the link's decision, not the resolver's, so a time picked by hand is the time
you get. The fragment often points at a row that is not in the table - a route
slow enough to regress is frequently not one called often enough to be heavy - so
the panel says so instead of silently not scrolling.

Three things about the pickers that each fail silently otherwise:

- they emit only their own `vdp:`/`vtp:` CustomEvents, so the contr... (continued)

Coverage Stats

59 of 60 new or added lines in 9 files covered. (98.33%)

3 existing lines in 1 file now uncovered.

3259 of 3463 relevant lines covered (94.11%)

23.23 hits per line