-
Notifications
You must be signed in to change notification settings - Fork 8.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
Fix issue with long values in TSVB static metric #40256
Conversation
Pinging @elastic/kibana-app |
💚 Build Succeeded |
@@ -78,11 +78,12 @@ export const bucketTransform = { | |||
}, | |||
static: bucket => { | |||
checkMetric(bucket, ['value']); | |||
const isDecimalValue = !Number.isInteger(Number(bucket.value)); |
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.
Maybe we can move it into helper 'method' to reuse it in future.
Also looks like it returns 'true' if bucket.value is string.
!Number.isInteger(Number('stringValue')); /// => true
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 don't think this line would justify a utility method, especially as you mentioned it's not very generic, since it works because we know that this will be a valid number in this place, generated by TSVB.
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.
what about to use RegExp here instead?
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.
Why would you prefer using regex, if we can use a native Number method to check the same?
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 know that we "sure" that the number in this place is a valid number, but I never trust code, so I'd also like to have a small check for NaN
values here. It doesn't hurt the code having one more check
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.
Code LGTM, I'd prefer one more check on that bucket.value
instead of a blind trust on the number correctness
@@ -78,11 +78,12 @@ export const bucketTransform = { | |||
}, | |||
static: bucket => { | |||
checkMetric(bucket, ['value']); | |||
const isDecimalValue = !Number.isInteger(Number(bucket.value)); |
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 know that we "sure" that the number in this place is a valid number, but I never trust code, so I'd also like to have a small check for NaN
values here. It doesn't hurt the code having one more check
@@ -78,11 +78,13 @@ export const bucketTransform = { | |||
}, | |||
static: bucket => { | |||
checkMetric(bucket, ['value']); | |||
// Anything containing a decimal point or an exponent is considered decimal value | |||
const isDecimalValue = bucket.value.match(/[.e]/i); |
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.
👍
But probably it make sense to wrap it Boolean(bucket.value.match(/[.e]/i))
. In case of false isDecimalValue === undefined
Also this solution works only if bucket.value has string value. I still think that we can create a helper method for that because the following code can confuse
Boolean(Number(bucket.value).toString().match(/[.e]/i))
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.
As long as we're inside JS I think checking for null
as a falsey value is fine, but I can wrap it. I cannot convert it to a number, because of the issue you pointed out that it will actually create the 64 bit rounding issues for the check, but then when we later write the script the string value won't have those, so Number('1231123112631231233.123').toString() == "1231123112631231200"
meaning we will append a L
and then Elasticsearch will fail because it's not a valid long.
💔 Build Failed |
Jenkins, test this - timeout issue |
💚 Build Succeeded |
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!
💚 Build Succeeded |
* Fix issue with long values in TSVB static metric * Handle numeric values with decimal zeros * Work properly with exponential values * Wrap into boolean
* Fix issue with long values in TSVB static metric * Handle numeric values with decimal zeros * Work properly with exponential values * Wrap into boolean
Summary
Fixes #28842
This makes sure that the user can also enter large static values, by using the
long
suffix in Painless/Java for all integer values. Since the user should still be able to use decimal numbers, we must check beforehand if the value is an integer and if not use the value as it is (double in painless).Checklist
Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.[ ] This was checked for cross-browser compatibility, including a check against IE11[ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support[ ] Documentation was added for features that require explanation or tutorials[ ] This was checked for keyboard-only and screenreader accessibilityFor maintainers
[ ] This was checked for breaking API changes and was labeled appropriately