Skip to content

PromQL: min_of / max_of scalar reducers unsupported #89

Description

@zzylol

Summary

min_of(s1, s2, …) and max_of(s1, s2, …) parse but are rejected (UnsupportedFunction). Split out of #51, which landed the extra *_over_time reducers and the sort family.

Per the parser signature they are n-ary scalar reducers: vec![Scalar, Scalar] variadic → Scalar. min_of(1, 2, 3) → the scalar 1.

Corpus impact

~14 rejections.

Why deferred

In the corpus these are almost always nested with the step() / range() scalar helpers inside range-selector / offset / @ positions — all of which are themselves unsupported:

count_over_time(metric1_total[min_of(step()+1, 1h)])
metric1_total offset min_of(step(), 1s)

So min_of/max_of can't be exercised end-to-end until step()/range() and dynamic range/offset expressions land. They also need a scalar-reduction representation: the current QueryExpr::Scalar(f64) leaf only holds a constant, so a non-constant min_of(step(), …) has nowhere to go. A constant-only fold (min_of(1,2)Scalar(1)) is possible but wouldn't help the real corpus cases.

Design questions: a scalar n-ary min/max expression node (or fold at num_expr for the constant case); dependency on step()/range() scalar helpers; dynamic range/offset support.

Pin

min_of_max_of_are_rejected__GAP in crates/frontend-promql/tests/promql_conformance.rs (§U).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions