Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update vectorAggEvaluator to fail for expressions without grouping #5544

Merged
merged 1 commit into from
Mar 4, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 8 additions & 5 deletions pkg/logql/evaluator.go
Original file line number Diff line number Diff line change
Expand Up @@ -178,7 +178,7 @@ func (ev *DefaultEvaluator) StepEvaluator(
&logproto.SampleQueryRequest{
Start: q.Start().Add(-rangExpr.Left.Interval).Add(-rangExpr.Left.Offset),
End: q.End().Add(-rangExpr.Left.Offset),
Selector: e.String(), // intentionally send the the vector for reducing labels.
Selector: e.String(), // intentionally send the vector for reducing labels.
Shards: q.Shards(),
},
})
Expand Down Expand Up @@ -217,6 +217,9 @@ func vectorAggEvaluator(
expr *VectorAggregationExpr,
q Params,
) (StepEvaluator, error) {
if expr.Grouping == nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where does it panic, it's possible to have no groups for vector and range vector operation ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It panics if a VectorAggregationExpr is created with Grouping as nil. The VectorAggregationExpr should always have a Grouping, even in a simple expression without grouping. Therefore, this should never happen, but it is still possible that a VectorAggregationExpr is created without a Grouping, so this seems a good safe check.

I came up with this problem in the Split by range epic when creating a VectorAggregationExpr from a RangeAggregationExpr, because the former always needs a grouping but the latter has the grouping set to nil. The solution is here: 0c291f1

return nil, errors.Errorf("aggregation operator '%q' without grouping", expr.Operation)
}
nextEvaluator, err := ev.StepEvaluator(ctx, ev, expr.Left, q)
if err != nil {
return nil, err
Expand Down Expand Up @@ -553,7 +556,7 @@ func binOpStepEvaluator(
ctx, cancel := context.WithCancel(ctx)
g := errgroup.Group{}

// We have two non literal legs,
// We have two non-literal legs,
// load them in parallel
g.Go(func() error {
var err error
Expand Down Expand Up @@ -669,7 +672,7 @@ func vectorBinop(op string, opts *BinOpOptions, lhs, rhs promql.Vector, lsigs, r
matchedSigs := make(map[uint64]map[uint64]struct{})
results := make(promql.Vector, 0)

// Add all rhs samples to a map so we can easily find matches later.
// Add all rhs samples to a map, so we can easily find matches later.
for i, sample := range rhs {
sig := rsigs[i]
if rightSigs[sig] != nil {
Expand Down Expand Up @@ -1059,7 +1062,7 @@ func mergeBinOp(op string, left, right *promql.Sample, filter, isVectorCompariso

if filter {
// if a filter-enabled vector-wise comparison has returned non-nil,
// ensure we return the left hand side's value (2) instead of the
// ensure we return the left-hand side's value (2) instead of the
// comparison operator's result (1: the truthy answer)
if res != nil {
return left
Expand All @@ -1069,7 +1072,7 @@ func mergeBinOp(op string, left, right *promql.Sample, filter, isVectorCompariso
}

// literalStepEvaluator merges a literal with a StepEvaluator. Since order matters in
// non commutative operations, inverted should be true when the literalExpr is not the left argument.
// non-commutative operations, inverted should be true when the literalExpr is not the left argument.
func literalStepEvaluator(
op string,
lit *LiteralExpr,
Expand Down