-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Sort time series indices by time range in GetDataStreams API #107967
Conversation
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
Hi @lkts, I've created a changelog YAML for you. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! I left one question.
currentMergedRange = new Tuple<>(currentMergedRange.v1(), end); | ||
} else if (currentMergedRange.v2().compareTo(start) < 0) { | ||
mergedRanges.add(currentMergedRange); | ||
currentMergedRange = new Tuple<>(start, end); | ||
} else { | ||
String message = "previous backing index [" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the indices getting sorted, I think don't we will ever log this warning? Maybe we should remove it and replace this with an assert
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is a "should never happen" thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Previously this logic assumed that time series indices are sorted by their time series range. This is problematic because data stream APIs don't actually enforce this invariant. As seen in below issues it is possible to add an index to data stream that will break the sort order either manually or via DSL.
This PR simply sorts indices in needed order before working with them. It seems appropriate given that this API is not performance sensitive.
Closes #102088, #106890.