-
Notifications
You must be signed in to change notification settings - Fork 24.3k
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
Failure in HDRPercentilesIT.testScriptSingleValued #92822
Comments
Pinging @elastic/es-analytics-geo (Team:Analytics) |
In fact I seem to be getting something similar on other tests in the same suite too - at least:
|
Oh this failed in |
Muted in a2adedf. |
I investigated this isssue and I think the problem is the following. When creating a sketch for a HdrHistogram we need to provide the As an additional note...testing in the main branch I could reproduce the issue for test
|
For empty histogram aggregations we instantiate by default a DoubleHistogram with 3 significant digits precision. The test generates a random value for the number of significant digits that is in the range [0, 5]. As a result, if the test runs with 4 or 5 significant value digits but the HdrHistogram sketch only uses 3, checking errors on results fails since all computations are done with lower than expected precision. The issue happens at reduction time in AbstractInternalHDRPercentiles when merging histograms coming from different shards. If a shard returns no data the sketch is empty but uses 3 significant digits, while for non empty results the correct number of digits is used. Now, depending on the order sketches are merged it might happen, for instance, that we merge a sketch using 4 or 5 significant digits into one using 3 significant digits (used for the empty result). The result, will then use whatever precision is used by the first "merged" object created. This in some cases leads to correct result and sometimes not. Here, when merging histograms, we always use the one with higher value of numberOfSignificantValueDigits so to avoid reducing precision of the result. Note that, as a result of this merging strategy, we can even use just 0 digits precision for empty results and save on some serialization/deserialization for empty histograms. Resolves #92822
For empty histogram aggregations we instantiate by default a DoubleHistogram with 3 significant digits precision. The test generates a random value for the number of significant digits that is in the range [0, 5]. As a result, if the test runs with 4 or 5 significant value digits but the HdrHistogram sketch only uses 3, checking errors on results fails since all computations are done with lower than expected precision. The issue happens at reduction time in AbstractInternalHDRPercentiles when merging histograms coming from different shards. If a shard returns no data the sketch is empty but uses 3 significant digits, while for non empty results the correct number of digits is used. Now, depending on the order sketches are merged it might happen, for instance, that we merge a sketch using 4 or 5 significant digits into one using 3 significant digits (used for the empty result). The result, will then use whatever precision is used by the first "merged" object created. This in some cases leads to correct result and sometimes not. Here, when merging histograms, we always use the one with higher value of numberOfSignificantValueDigits so to avoid reducing precision of the result. Note that, as a result of this merging strategy, we can even use just 0 digits precision for empty results and save on some serialization/deserialization for empty histograms. Resolves elastic#92822
For empty histogram aggregations we instantiate by default a DoubleHistogram with 3 significant digits precision. The test generates a random value for the number of significant digits that is in the range [0, 5]. As a result, if the test runs with 4 or 5 significant value digits but the HdrHistogram sketch only uses 3, checking errors on results fails since all computations are done with lower than expected precision. The issue happens at reduction time in AbstractInternalHDRPercentiles when merging histograms coming from different shards. If a shard returns no data the sketch is empty but uses 3 significant digits, while for non empty results the correct number of digits is used. Now, depending on the order sketches are merged it might happen, for instance, that we merge a sketch using 4 or 5 significant digits into one using 3 significant digits (used for the empty result). The result, will then use whatever precision is used by the first "merged" object created. This in some cases leads to correct result and sometimes not. Here, when merging histograms, we always use the one with higher value of numberOfSignificantValueDigits so to avoid reducing precision of the result. Note that, as a result of this merging strategy, we can even use just 0 digits precision for empty results and save on some serialization/deserialization for empty histograms. Resolves elastic#92822
CI Link
https://gradle-enterprise.elastic.co/s/4loz5k2jllcvg
Repro line
./gradlew ':server:internalClusterTest' --tests "org.elasticsearch.search.aggregations.metrics.HDRPercentilesIT.testScriptSingleValued" -Dtests.seed=928B8BBC20C73401 -Dtests.locale=de-CH -Dtests.timezone=America/Argentina/Catamarca -Druntime.java=19
Does it reproduce?
Yes
Applicable branches
#92817 (a small change over main)
Failure history
No response
Failure excerpt
I encountered this a few times in #92817, which is effectively
main
plus the following patch which should not cause any failures:The failure is as follows:
The text was updated successfully, but these errors were encountered: