Name the alert's grid point and read boundaries off the base tables

[epompeii]

The field

JsonAlert gains parameter, the grid point the alert fired on. It sits between benchmark and metric, because that is the order the dimensions run in: branch, testbed, benchmark, parameters, measure, metric.

Two grid points of one benchmark under one threshold used to raise two alerts that read identically: same benchmark, same measure, same threshold, nothing to tell them apart. Now the alert names its grid point.

Every surface that returns an alert carries it:

• the alerts list, GET /v0/projects/{project}/alerts
• the alert detail, GET /v0/projects/{project}/alerts/{alert}, and its PATCH response
• the alerts a report response embeds

The perf response's JsonPerfAlert is unchanged. It is a slim reference, and the line it hangs off already names its grid point.

The reader moves

Both alert readers move off the metric_boundary view and onto the base tables. An alert names its boundary, the boundary names its metric row, and that row names the report it landed in and the grid point it was measured under, so each hop is an identifier seek off the hop before it.

The metric triple is assembled from the value row the boundary was computed for plus its lower_value and upper_value siblings, which is the same assembly the metric endpoint does. That assembly is now shared rather than written twice.

The move is what the next layer needs. The view carries at most one boundary per metric row, and a metric row is about to be allowed several, so a reader that reached its boundary through the view's left join would fan one alert out into one per boundary.

No reader joins a boundary through the view

git grep -n 'view::metric_boundary'

One match, in services/console/src/chunks/engineering/sqlite-performance-tuning/bonus-bug-rust-left-join.mdx: a code sample quoted in a blog post, not a query. There is no other reference anywhere in the tree.

The view itself stays, and the migration that holds its column list unchanged stays pinned to it. Its Rust model is gone, because nothing reads it now.

Compatibility

Every field an alert carried before carries exactly what it carried before. metric included: it is still required, and it is still the triple built around the row the boundary was computed for.

The claim is stated as a fixture rather than asserted. A two grid point history under one threshold is pinned key set and values both, against what the previous shape gave that same fixture: the key set is the old one plus parameter, and every old key holds its old value. Three more fixtures pin the triple for a metric row with both bounds, one bound, and no bounds. The report response's embedded alerts and the alerts endpoint's alerts are pinned equal for the same report.

cargo gen-types regenerates the OpenAPI spec and the TypeScript types.

[github-actions]

Bencher Report

Project	Bencher
Branch	u/ep/parameters-api/alerts
Testbed	intel-v1

Click to view all benchmark results

Benchmark	Latency	Benchmark Result microseconds (µs) (Result Δ%)	Upper Boundary microseconds (µs) (Limit %)
Adapter::Json	📈 view plot 🚷 view threshold	5.26 µs (+10.48%) Baseline: 4.76 µs	5.56 µs (94.55%)
Adapter::Magic (JSON)	📈 view plot 🚷 view threshold	5.08 µs (+9.94%) Baseline: 4.62 µs	5.34 µs (95.06%)
Adapter::Magic (Rust)	📈 view plot 🚷 view threshold	27.89 µs (+6.94%) Baseline: 26.08 µs	28.42 µs (98.16%)
Adapter::Rust	📈 view plot 🚷 view threshold	4.66 µs (+26.26%) Baseline: 3.69 µs	5.31 µs (87.71%)
Adapter::RustBench	📈 view plot 🚷 view threshold	4.66 µs (+26.46%) Baseline: 3.68 µs	5.29 µs (88.15%)

🐰 View full continuous benchmarking report in Bencher