Check any metric of any variant, and let every matching threshold fire

[epompeii]

A threshold checked one thing: the value metric of every variant of its measure.
A benchmark now reports one variant per distinct parameters and as many
metrics as its harness measured, and neither was addressable. A project that
wanted p99 watched on the one configuration where it matters had nowhere to say
so.

The model

A threshold gains two optional fields.

metric is the name it checks. A threshold that names none checks the conventional
value name: a threshold always checks exactly one name, and a bare one never checks
all of them.

parameters is a filter over variants: a list of partial parameters, an OR across
the list and a subset match within each entry. A filter names only the keys it cares
about, so [{"size": 512}] matches a variant that also pins threads. A
threshold with no filter checks every variant.

Both defaults are what every threshold already does, so no existing row moves and no
project's alert volume changes.

Every matching threshold fires

There is no winner: not in checking, not in display. A variant that a bare
threshold and a filtered threshold both match earns a boundary from each and, on a
regression, an alert from each. Two thresholds asked for that row to be watched, so
two of them are told about it. This is deliberate and it is pinned by a test rather
than smoothed over.

Identity, and the null semantics

Identity is the three dimensions plus the two new fields, under the null semantics
they carry. SQLite treats nulls as distinct in a unique index, so two bare
thresholds on one branch, testbed, and measure would no longer collide under a plain
unique key over the five columns, and an explicit value would sit beside an absent
one.

The key is declared over the effective values instead:

CREATE UNIQUE INDEX index_threshold_dimensions ON threshold(
    branch_id,
    testbed_id,
    COALESCE(parameters, x''),
    measure_id,
    COALESCE(metric, 'value')
);

x'' is a value no stored filter can take, because a filter that matches everything
is stored as NULL.

The wire canonicalizes into those stored values. An explicit value and an absent
name are one threshold. An empty filter, a filter holding the empty entry, and an
absent filter are one threshold, because empty parameters are a subset of every
variant's. A filter has one spelling, because its entries sort by their RFC 8785
canonical bytes, duplicates collapse, and an entry another entry already covers is
dropped: [{"a": 1}, {"a": 1.0}] and [{"a": 1}, {"a": 1, "b": 2}] are both the one
entry [{"a": 1}], because every variant the wider entry matches the narrower one
matches too. The empty entry rule is that rule's special case.
The wire accepts any order and any spelling; the response returns the canonical form.

The sample keys on the name

The historical query behind detection filters on the threshold's metric name, so a
threshold on p99 is tested against p99 rows and never against the value rows
beside them. The per variant separation is unchanged: a threshold still samples
one variant's history and never the benchmark's variants pooled.

The boundary key

boundary keys on (metric_id, threshold_id) rather than on metric_id alone,
because a metric row may now carry a boundary per threshold that checked it. Both
threshold and boundary are rebuilt, each with its unique keys built after the
copy rather than declared on the table, which is what keeps the rebuild at the cost
of the scan. down.sql restores both old shapes, and because the old schema has no
shape for a threshold that names a metric or checks only some variants, it deletes
every such threshold with its models, boundaries, and alerts rather than flattening
it into a bare one.

Responses

JsonAlert gains value, the metric value the alert fired on, and its metric
triple becomes optional. The triple is a convention over the value name, so an
alert on any other name has none; every alert a threshold could raise before this
carries the triple exactly as it did, so no existing response changes. The checked
name is readable at alert.threshold.metric.

The base of this branch carried a debug_assert_eq! in into_json_for_report
holding that a checked row is always a point estimate. That is the invariant this
branch retires, so the assertion is removed by design rather than by accident, and
the comment in its place says so.

The deprecated singular threshold, boundary, and alert fields carry the bare
threshold's check and no other's, wherever they appear. That is precisely what a
caller from before named checking has always been shown: a row that only a named or
filtered threshold checks reports no check in them at all. Where a list of boundaries
is returned, it is ordered by the threshold UUID, which is creation order for a
UUIDv7 and deterministic for the UUIDv4 a threshold minted before the move to
UUIDv7. Nothing about that order is a ranking.

Every entry of that list names what its threshold checks: JsonThresholdModel gains
parameters and metric, both absent when the threshold takes the default, so a
reader looking at two boundaries on one row can tell the filtered one from the bare
one without a second request. The hand written ParameterFilter and ParameterSet
schemas now carry the caps they enforce, so a generated client can see them.

The in-report thresholds.models map is unchanged and still addresses the bare
threshold. A map that names a measure and a model says nothing about a name or a
variant, so it neither creates nor resets anything narrower. A threshold that
checks a name or only some variants is created through the thresholds endpoint.

[github-actions]

Bencher Report

Project	Bencher
Branch	u/ep/parameters-api/thresholds
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.18 µs (+6.95%) Baseline: 4.84 µs	5.87 µs (88.20%)
Adapter::Magic (JSON)	📈 view plot 🚷 view threshold	4.96 µs (+5.85%) Baseline: 4.69 µs	5.58 µs (88.91%)
Adapter::Magic (Rust)	📈 view plot 🚷 view threshold	27.84 µs (+5.49%) Baseline: 26.39 µs	29.78 µs (93.50%)
Adapter::Rust	📈 view plot 🚷 view threshold	4.68 µs (+20.89%) Baseline: 3.87 µs	6.00 µs (77.99%)
Adapter::RustBench	📈 view plot 🚷 view threshold	4.64 µs (+20.08%) Baseline: 3.87 µs	5.98 µs (77.64%)

🐰 View full continuous benchmarking report in Bencher

[epompeii]

Review after the rebase onto devel

Rebased onto devel with the terminology sweep (grid point to variant, gate to check, named value to metric). Two independent reviews and an adjudication found no major findings in this layer.

Rebase changes:

• Conflicts with devel's boundary_json and deprecated_check renames resolved: the bare threshold's singular fields are now carried as bare_check.
• Devel's boundary history query is now the hand-built HistoryQuery that walks the head newest first. This layer binds the threshold's metric name into it in place of value, leaving devel's SQL text unchanged, and devel's own query test builds its fixture as a bare value threshold.
• Threshold::gates is now Threshold::checks.
• Test fixtures pin an explicit perf start_time, because devel's four week default window postdates the 2024 fixture dates.
• into_report_results_json grew past the clippy line limit after the rebase, so its per row fold is extracted into push_result_row.

Cleanups applied from review: the namedgate fixture label, the create_threshold_with_identity test helper rename, and a narrowed comment in metric_migration.rs.