-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Fix wrong error upper bound when performing incremental reductions #43874
Conversation
Pinging @elastic/es-analytics-geo |
I've updated the PR. Can we finish this? |
Oops, looks like diff is unreadable now. |
Rebased. |
@polyfractal, @javanna, @colings86, can someone answer, please? |
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.
I think this is right. I'm really sorry we lost track of this one. It seems like a good change. I left a small question, but I think its right.
@imotov thought I knew this code fairly well. I'm not 100% confident in my ability to reason about it all in my head but with the test change and his confidence I'm happy with the change.
@@ -51,7 +52,14 @@ protected InternalMappedTerms(String name, BucketOrder reduceOrder, BucketOrder | |||
*/ | |||
protected InternalMappedTerms(StreamInput in, Bucket.Reader<B> bucketReader) throws IOException { | |||
super(in); | |||
docCountError = in.readZLong(); | |||
if (in.getVersion().onOrAfter(Version.V_8_0_0)) { // todo fix after backport | |||
docCountError = in.readOptionalLong(); |
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.
Should this stay a zlong?
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.
@nik9000 why was it a zlong in the first place? Can errors be negative?
Good question! Maybe it should be vlong? I'm not sure how it got that way
in the first place.
…On Thu, Jul 1, 2021, 15:49 Igor Motov ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In
server/src/main/java/org/elasticsearch/search/aggregations/bucket/terms/InternalMappedTerms.java
<#43874 (comment)>
:
> @@ -51,7 +52,14 @@ protected InternalMappedTerms(String name, BucketOrder reduceOrder, BucketOrder
*/
protected InternalMappedTerms(StreamInput in, Bucket.Reader<B> bucketReader) throws IOException {
super(in);
- docCountError = in.readZLong();
+ if (in.getVersion().onOrAfter(Version.V_8_0_0)) { // todo fix after backport
+ docCountError = in.readOptionalLong();
@nik9000 <https://github.com/nik9000> why was it a zlong in the first
place? Can errors be negative?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#43874 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABUXIQWY26EEDI4XDXEWO3TVTBFJANCNFSM4H43R3RA>
.
|
@elasticmachine update branch |
@elasticmachine test this please |
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.
I've read this twice now, and I think it's okay. Very tricky.
@@ -1014,4 +1030,17 @@ public void testFixedDocs() throws Exception { | |||
assertThat(bucket.getDocCountError(), equalTo(29L)); | |||
} | |||
|
|||
public void testIncrementalReductionBug() { |
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.
I'm nitpicking, but it'd be good to explain exactly what this is testing, or at least link to the issue. In a year, we'll have no idea what it's supposed to do.
@elasticmachine update branch |
@elasticmachine test this please |
@elasticmachine run elasticsearch-ci/part-1 |
…lastic#43874) When performing incremental reductions, 0 value of docCountError may mean that the error was not previously calculated, or that the error was indeed previously calculated and its value was 0. We end up rejecting true values set to 0 this way. This may lead to wrong upper bound of error in result. To fix it, this PR makes docCountError nullable. null values mean that error was not calculated yet. Fixes elastic#40005 Co-authored-by: Igor Motov <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
Fix docCountError calculation in case of multiple reduces. It fixes 2 mistakes in elastic#43874. The first error was introduced in the original PR, where unknown doc count errors were initialized equal to 0, the second was introduced during in order to fix the first one by ignoring these 0s, which essentially disabled the original fix. Fixes elastic#75667
Fix docCountError calculation in case of multiple reduces. It fixes 2 mistakes in #43874. The first error was introduced in the original PR, where unknown doc count errors were initialized equal to 0, the second was introduced during in order to fix the first one by ignoring these 0s, which essentially disabled the original fix. Fixes #75667
…lastic#43874) When performing incremental reductions, 0 value of docCountError may mean that the error was not previously calculated, or that the error was indeed previously calculated and its value was 0. We end up rejecting true values set to 0 this way. This may lead to wrong upper bound of error in result. To fix it, this PR makes docCountError nullable. null values mean that error was not calculated yet. Fixes elastic#40005 Co-authored-by: Igor Motov <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
Fix docCountError calculation in case of multiple reduces. It fixes 2 mistakes in elastic#43874. The first error was introduced in the original PR, where unknown doc count errors were initialized equal to 0, the second was introduced during in order to fix the first one by ignoring these 0s, which essentially disabled the original fix. Fixes elastic#75667
…ons (#43874) (#76475) When performing incremental reductions, 0 value of docCountError may mean that the error was not previously calculated, or that the error was indeed previously calculated and its value was 0. We end up rejecting true values set to 0 this way. This may lead to wrong upper bound of error in result. To fix it, this PR makes docCountError nullable. null values mean that error was not calculated yet. Fixes #40005, #75667 Co-authored-by: Nikita Glashenko <[email protected]>
I was expecting this to address an issue I found in CCSDuelIT, but that does not seem to be the case. See #85538 . We still have an awaitsfix and a failure when we try and remove it. Could you help with this? |
When performing incremental reductions,
0
value ofdocCountError
may mean that the error was not previously calculated, or that the error was indeed previously calculated and its value was 0. We end up rejecting true values set to 0 this way.This may lead to wrong upper bound of error in result.
To fix it, this PR makes
docCountError
nullable.null
values mean that error was not calculated yet.Fixes #40005