Skip to content

Conversation

not-napoleon
Copy link
Member

@not-napoleon not-napoleon commented May 2, 2022

Resolves #85928

The after-key parsing is pretty weird, and there are probably more bugs there. I did not take the opportunity to refactor the whole thing, but we should. This fixes the immediate problem by treating after keys as bytes refs when we don't have a field but think we want a keyword. We were already doing that if the user asked for a missing bucket, this just extends the behavior in the case that we don't.

Long term, the terms Composite source (and probably other Composite sources) should have specializations for unmapped fields. That's the direction we want to take aggs in general.

@not-napoleon not-napoleon changed the title Parsing after key doesn't care about missing Less jank in after-key parsing for unmapped fields May 3, 2022
@not-napoleon not-napoleon marked this pull request as ready for review May 3, 2022 13:43
@elasticmachine elasticmachine added the Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) label May 3, 2022
@elasticmachine
Copy link
Collaborator

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

@elasticsearchmachine
Copy link
Collaborator

Hi @not-napoleon, I've created a changelog YAML for you.

Copy link
Contributor

@csoulios csoulios left a comment

Choose a reason for hiding this comment

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

LGTM!

For future reference when we decide to refactor this part, let's have in mind that a BytesRef field can also be an encoded _tsid field. (See #81998)

@not-napoleon not-napoleon merged commit 6e0a0f9 into elastic:master May 3, 2022
@not-napoleon not-napoleon deleted the 85928-composite-after-key-type branch May 3, 2022 17:23
@elasticsearchmachine
Copy link
Collaborator

💚 Backport successful

Status Branch Result
8.2

not-napoleon added a commit to not-napoleon/elasticsearch that referenced this pull request May 3, 2022
This addresses a bug where specifying an integer after key on an unmapped field for a terms composite source caused the shard to error.  

Resolves elastic#85928

The after-key parsing is pretty weird, and there are probably more bugs there. I did not take the opportunity to refactor the whole thing, but we should. This fixes the immediate problem by treating after keys as bytes refs when we don't have a field but think we want a keyword. We were already doing that if the user asked for a missing bucket, this just extends the behavior in the case that we don't.

Long term, the terms Composite source (and probably other Composite sources) should have specializations for unmapped fields. That's the direction we want to take aggs in general.
elasticsearchmachine pushed a commit that referenced this pull request May 3, 2022
This addresses a bug where specifying an integer after key on an unmapped field for a terms composite source caused the shard to error.  

Resolves #85928

The after-key parsing is pretty weird, and there are probably more bugs there. I did not take the opportunity to refactor the whole thing, but we should. This fixes the immediate problem by treating after keys as bytes refs when we don't have a field but think we want a keyword. We were already doing that if the user asked for a missing bucket, this just extends the behavior in the case that we don't.

Long term, the terms Composite source (and probably other Composite sources) should have specializations for unmapped fields. That's the direction we want to take aggs in general.
@lockewritesdocs lockewritesdocs changed the title Less jank in after-key parsing for unmapped fields Less complexity in after-key parsing for unmapped fields May 19, 2022
not-napoleon added a commit to not-napoleon/elasticsearch that referenced this pull request Jun 30, 2023
This addresses a bug where specifying an integer after key on an unmapped field for a terms composite source caused the shard to error.  

Resolves elastic#85928

The after-key parsing is pretty weird, and there are probably more bugs there. I did not take the opportunity to refactor the whole thing, but we should. This fixes the immediate problem by treating after keys as bytes refs when we don't have a field but think we want a keyword. We were already doing that if the user asked for a missing bucket, this just extends the behavior in the case that we don't.

Long term, the terms Composite source (and probably other Composite sources) should have specializations for unmapped fields. That's the direction we want to take aggs in general.
not-napoleon added a commit that referenced this pull request Jul 3, 2023
Resolves #85928

The after-key parsing is pretty weird, and there are probably more bugs there. I did not take the opportunity to refactor the whole thing, but we should. This fixes the immediate problem by treating after keys as bytes refs when we don't have a field but think we want a keyword. We were already doing that if the user asked for a missing bucket, this just extends the behavior in the case that we don't.

Long term, the terms Composite source (and probably other Composite sources) should have specializations for unmapped fields. That's the direction we want to take aggs in general.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Analytics/Aggregations Aggregations >bug Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) v8.2.1 v8.3.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Partial shard failures for non-string composite after_key values
4 participants