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
https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW
Found in the #540 review.
Problem
The MetricsQL frontend maps
rate,increase,deltaandchangesto the sameAggIntents as PromQL. VictoriaMetrics computes them differently: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
https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW