Fix bug with multiple spatial aggs filtering in ES|QL#142332
Merged
craigtaverner merged 5 commits intoelastic:mainfrom Feb 12, 2026
Merged
Fix bug with multiple spatial aggs filtering in ES|QL#142332craigtaverner merged 5 commits intoelastic:mainfrom
craigtaverner merged 5 commits intoelastic:mainfrom
Conversation
Collaborator
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
Collaborator
|
Hi @craigtaverner, I've created a changelog YAML for you. |
ncordon
approved these changes
Feb 12, 2026
ncordon
reviewed
Feb 12, 2026
Contributor
ncordon
left a comment
There was a problem hiding this comment.
The node info tests need some tweaking
Collaborator
💔 Backport failed
You can use sqren/backport to manually backport by running |
craigtaverner
added a commit
to craigtaverner/elasticsearch
that referenced
this pull request
Feb 12, 2026
When using a WHERE clause within the STATS of a spatial aggregation, and there are more than one aggregation function, the results are incorrect, and reflect the values of the first aggregating function. With some investigation by Cursor it turns out this is a side effect of the fact that the replaceChildren function was not capturing the filter (and not the window or field-extract preference either). This was probably due to the first implementation of the filter in elastic#113735 back in October 2024, which appears to have not updated this method in the SpatialCentroid class, although it did update that method in other aggregations. Then SpatialExtents, inspired by SpatialCentroid code, inherited this flaw. Since it is rare to perform queries like this, and our test suite did not include any, we did not notice this until working on a more advanced feature, extracting a combination of both centroid and bounds from shape doc-values, which requires both centroid and shape aggregations in the same query.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Feb 13, 2026
) When using a WHERE clause within the STATS of a spatial aggregation, and there are more than one aggregation function, the results are incorrect, and reflect the values of the first aggregating function. With some investigation by Cursor it turns out this is a side effect of the fact that the replaceChildren function was not capturing the filter (and not the window or field-extract preference either). This was probably due to the first implementation of the filter in #113735 back in October 2024, which appears to have not updated this method in the SpatialCentroid class, although it did update that method in other aggregations. Then SpatialExtents, inspired by SpatialCentroid code, inherited this flaw. Since it is rare to perform queries like this, and our test suite did not include any, we did not notice this until working on a more advanced feature, extracting a combination of both centroid and bounds from shape doc-values, which requires both centroid and shape aggregations in the same query.
craigtaverner
added a commit
to craigtaverner/elasticsearch
that referenced
this pull request
Feb 13, 2026
elastic#142385) When using a WHERE clause within the STATS of a spatial aggregation, and there are more than one aggregation function, the results are incorrect, and reflect the values of the first aggregating function. With some investigation by Cursor it turns out this is a side effect of the fact that the replaceChildren function was not capturing the filter (and not the window or field-extract preference either). This was probably due to the first implementation of the filter in elastic#113735 back in October 2024, which appears to have not updated this method in the SpatialCentroid class, although it did update that method in other aggregations. Then SpatialExtents, inspired by SpatialCentroid code, inherited this flaw. Since it is rare to perform queries like this, and our test suite did not include any, we did not notice this until working on a more advanced feature, extracting a combination of both centroid and bounds from shape doc-values, which requires both centroid and shape aggregations in the same query.
Contributor
Author
|
Manually backporting to 9.2 and 8.19 in #142487 |
elasticsearchmachine
pushed a commit
that referenced
this pull request
Feb 13, 2026
) (#142487) When using a WHERE clause within the STATS of a spatial aggregation, and there are more than one aggregation function, the results are incorrect, and reflect the values of the first aggregating function. With some investigation by Cursor it turns out this is a side effect of the fact that the replaceChildren function was not capturing the filter (and not the window or field-extract preference either). This was probably due to the first implementation of the filter in #113735 back in October 2024, which appears to have not updated this method in the SpatialCentroid class, although it did update that method in other aggregations. Then SpatialExtents, inspired by SpatialCentroid code, inherited this flaw. Since it is rare to perform queries like this, and our test suite did not include any, we did not notice this until working on a more advanced feature, extracting a combination of both centroid and bounds from shape doc-values, which requires both centroid and shape aggregations in the same query.
craigtaverner
added a commit
to craigtaverner/elasticsearch
that referenced
this pull request
Feb 16, 2026
elastic#142385) (elastic#142487) When using a WHERE clause within the STATS of a spatial aggregation, and there are more than one aggregation function, the results are incorrect, and reflect the values of the first aggregating function. With some investigation by Cursor it turns out this is a side effect of the fact that the replaceChildren function was not capturing the filter (and not the window or field-extract preference either). This was probably due to the first implementation of the filter in elastic#113735 back in October 2024, which appears to have not updated this method in the SpatialCentroid class, although it did update that method in other aggregations. Then SpatialExtents, inspired by SpatialCentroid code, inherited this flaw. Since it is rare to perform queries like this, and our test suite did not include any, we did not notice this until working on a more advanced feature, extracting a combination of both centroid and bounds from shape doc-values, which requires both centroid and shape aggregations in the same query.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Feb 16, 2026
) (#142487) (#142533) When using a WHERE clause within the STATS of a spatial aggregation, and there are more than one aggregation function, the results are incorrect, and reflect the values of the first aggregating function. With some investigation by Cursor it turns out this is a side effect of the fact that the replaceChildren function was not capturing the filter (and not the window or field-extract preference either). This was probably due to the first implementation of the filter in #113735 back in October 2024, which appears to have not updated this method in the SpatialCentroid class, although it did update that method in other aggregations. Then SpatialExtents, inspired by SpatialCentroid code, inherited this flaw. Since it is rare to perform queries like this, and our test suite did not include any, we did not notice this until working on a more advanced feature, extracting a combination of both centroid and bounds from shape doc-values, which requires both centroid and shape aggregations in the same query.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When using a WHERE clause within the STATS of a spatial aggregation, and there are more than one aggregation function, the results are incorrect, and reflect the values of the first aggregating function. With some investigation by Cursor it turns out this is a side effect of the fact that the
replaceChildrenfunction was not capturing the filter (and not the window or field-extract preference either). This was probably due to the first implementation of the filter in #113735 back in October 2024, which appears to have not updated this method in theSpatialCentroidclass, although it did update that method in other aggregations. ThenSpatialExtents, inspired bySpatialCentroidcode, inherited this flaw. Since it is rare to perform queries like this, and our test suite did not include any, we did not notice this until working on a more advanced feature, extracting a combination of both centroid and bounds from shape doc-values, which requires both centroid and shape aggregations in the same query.This PR adds basic tests that validate the fix for points, and should be easy to back-port to all supported versions. A followup PR with support for the above mentioned doc-values extraction will expand the test suite to more complex combinations not supported in older versions.
Fixes #142329