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

Move pipeline agg validation to coordinating node #53669

Merged
merged 5 commits into from
Mar 23, 2020

Conversation

nik9000
Copy link
Member

@nik9000 nik9000 commented Mar 17, 2020

This moves the pipeline aggregation validation from the data node to the
coordinating node so that we, eventually, can stop sending pipeline
aggregations to the data nodes entirely. In fact, it moves it into the
"request validation" stage so multiple errors can be accumulated and
sent back to the requester for the entire request. We can't always take
advantage of that, but it'll be nice for folks not to have to play
whack-a-mole with validation.

This is implemented by replacing PipelineAggretionBuilder#validate
with:

protected abstract void validate(ValidationContext context);

The ValidationContext handles the accumulation of validation failures,
provides access to the aggregation's siblings, and implements a few
validation utility methods.

This moves the pipeline aggregation validation from the data node to the
coordinating node so that we, eventually, can stop sending pipeline
aggregations to the data nodes entirely. In fact, it moves it into the
"request validation" stage so multiple errors can be accumulated and
sent back to the requester for the entire request. We can't always take
advantage of that, but it'll be nice for folks not to have to play
whack-a-mole with validation.

This is implemented by replacing `PipelineAggretionBuilder#validate`
with:
```
protected abstract void validate(ValidationContext context);
```

The `ValidationContext` handles the accumulation of validation failures,
provides access to the aggregation's siblings, and implements a few
validation utility methods.
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-analytics-geo (:Analytics/Aggregations)

@nik9000
Copy link
Member Author

nik9000 commented Mar 17, 2020

This'll probably change some errors from 500s to 400s. I believe that'll be a net positive because I don't imagine anyone is relying on 500 errors for bad aggregation configuration.

@nik9000 nik9000 mentioned this pull request Mar 18, 2020
3 tasks
Copy link
Contributor

@polyfractal polyfractal left a comment

Choose a reason for hiding this comment

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

++ I like this. Left a few tiny notes and optional nits.

Should we add a note to the breaking changes doc? I'm onboard with the fact these should have been 4xx errors anyway, and it's unlikely someone was depending on these particular 5xx errors in their code...but it might be nice to note it in the docs anyway?

orderedPipelineAggregators = resolvePipelineAggregatorOrder(pipelineAggregatorBuilders, aggregationBuilders);
} catch (IllegalArgumentException iae) {
context.addValidationError(iae.getMessage());
return;
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we allow the validations to keep running down the tree, so we can tell the user all the problems at once?

Copy link
Member Author

Choose a reason for hiding this comment

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

I was tempted but I think the tree is pretty borked at this point and you'll end up with duplicate error messages all about the same thing. And I figured we were just returning a single error message right now so it probably isn't worse than it was before and we could do it later if we wanted it.

Copy link
Contributor

Choose a reason for hiding this comment

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

Makes sense to me 👍

}

@Override
public void validateParentAggSequentiallyOrdered(String type, String name) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Ahh yes, this thing. Would be nice someday if we could get rid of these instanceofs with some kind of isSequential() method on the agg.

Battle for another day :)

Copy link
Member Author

Choose a reason for hiding this comment

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

+++++++++++++

.findAny();
if (aggBuilder.isPresent()) {
if ((aggBuilder.get() instanceof MultiBucketAggregationBuilder) == false) {
throw new IllegalArgumentException("The first aggregation in " + PipelineAggregator.Parser.BUCKETS_PATH.getPreferredName()
context.addValidationError("The first aggregation in " + PipelineAggregator.Parser.BUCKETS_PATH.getPreferredName()
+ " must be a multi-bucket aggregation for aggregation [" + name + "] found :"
+ aggBuilder.get().getClass().getName() + " for buckets path: " + bucketsPaths[0]);
}
} else {
Copy link
Contributor

Choose a reason for hiding this comment

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

Optional: should we remove this else statement and just leave the context error as the last statement in the method?

I always feel like else are trappy/unnecessary when it's just doing some kind of error or return statement. Less rightward drift if we remove.

Totally optional, this might just be a quirk I've picked up :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Or, re-arrange so there's an isPresent() == false check first, and an instanceof check next, which avoids nesting.

But yeah, optional pending your preferences :D

@nik9000
Copy link
Member Author

nik9000 commented Mar 19, 2020

Should we add a note to the breaking changes doc? I'm onboard with the fact these should have been 4xx errors anyway, and it's unlikely someone was depending on these particular 5xx errors in their code...but it might be nice to note it in the docs anyway?

I think I have to do that as part of the backport, right?

@nik9000
Copy link
Member Author

nik9000 commented Mar 19, 2020

@polyfractal I believe I've done the things you asked! Thanks so much for the review.

@polyfractal
Copy link
Contributor

I think I have to do that as part of the backport, right?

🤦‍♂️ yes, yes I believe you're right.

@nik9000 nik9000 merged commit 569dffc into elastic:master Mar 23, 2020
nik9000 added a commit to nik9000/elasticsearch that referenced this pull request Mar 23, 2020
…c#53669)

This moves the pipeline aggregation validation from the data node to the
coordinating node so that we, eventually, can stop sending pipeline
aggregations to the data nodes entirely. In fact, it moves it into the
"request validation" stage so multiple errors can be accumulated and
sent back to the requester for the entire request. We can't always take
advantage of that, but it'll be nice for folks not to have to play
whack-a-mole with validation.

This is implemented by replacing `PipelineAggretionBuilder#validate`
with:
```
protected abstract void validate(ValidationContext context);
```

The `ValidationContext` handles the accumulation of validation failures,
provides access to the aggregation's siblings, and implements a few
validation utility methods.
nik9000 added a commit that referenced this pull request Mar 23, 2020
#54019)

This moves the pipeline aggregation validation from the data node to the
coordinating node so that we, eventually, can stop sending pipeline
aggregations to the data nodes entirely. In fact, it moves it into the
"request validation" stage so multiple errors can be accumulated and
sent back to the requester for the entire request. We can't always take
advantage of that, but it'll be nice for folks not to have to play
whack-a-mole with validation.

This is implemented by replacing `PipelineAggretionBuilder#validate`
with:
```
protected abstract void validate(ValidationContext context);
```

The `ValidationContext` handles the accumulation of validation failures,
provides access to the aggregation's siblings, and implements a few
validation utility methods.
nik9000 added a commit that referenced this pull request Mar 25, 2020
nik9000 added a commit that referenced this pull request Mar 25, 2020
jrodewig added a commit that referenced this pull request Sep 27, 2021
Adds a note to the pipeline aggregation docs for error status codes changed with #53669.
jrodewig added a commit that referenced this pull request Sep 27, 2021
…8328)

Adds a note to the pipeline aggregation docs for error status codes changed with #53669.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants