Repository navigation
MetricsQL: rate/increase/delta/changes use Prometheus semantics instead of VictoriaMetrics #653
Description
Found in the #540 review.
Problem
The MetricsQL frontend maps rate, increase, delta and changes to the same AggIntents as PromQL. VictoriaMetrics computes them differently:
- it uses the last sample before the window;
- it does not extrapolate.
So with a sparse counter, increase(m[5m]) is evaluated with Prometheus semantics and can differ from VictoriaMetrics. The query is accepted silently. This behavior predates the unified lowering: it was copied from the legacy MetricsQL frontend.
Why it is not rejected now
Rejecting these functions would break the MetricsQL golden tests (crates/frontend-metricsql/tests/lowering.rs, victoriametrics_go_golden.rs).
Follow-up
Add MetricsQL-specific intents, or a semantics flag on the existing ones, and evaluate them as VictoriaMetrics does. Until then, either reject the functions or document the difference.
🤖 Generated with Claude Code
Activity
zzylol commentedon Oct 12, 2026
One more from the #540 re-review: constant scalar arithmetic such as
2*3orup + (2*3)is rejected with "scalar root requires lower_metricsql_query", even when the caller already uses that function. Nothing wrong is computed, but the error points at the wrong cause. The parser keeps2*3as aBinaryOperator; only a bareNumberLiteral(and(5),-5, which the parser folds) is treated as a scalar. A fix is to constant-fold number-only binary expressions before those checks, as PromQL does.