Skip to content
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

[Bug]: span tags of type int64 may lose precision #3958 #4023

Closed
wants to merge 12 commits into from

Conversation

shubbham1215
Copy link
Contributor

@shubbham1215 shubbham1215 commented Nov 7, 2022

Avoid value precision loss

Signed-off-by: Shubham Sawaiker [email protected]

Which problem is this PR solving?

Short description of the changes

  • avoid display value precision loss in case of value overflow Number.MAX_VALUE

@shubbham1215 shubbham1215 requested a review from a team as a code owner November 7, 2022 19:46
@shubbham1215 shubbham1215 marked this pull request as draft November 7, 2022 19:50
@shubbham1215
Copy link
Contributor Author

@yurishkuro Could you please check this draft pull request? I suppose the types in domain_01.json and ui_01.json are to be different in case of large integer values.

@@ -122,6 +128,10 @@ func (fd fromDomain) convertKeyValues(keyValues model.KeyValues) []json.KeyValue
value = kv.Bool()
case model.Int64Type:
value = kv.Int64()
if kv.Int64() > js_limit_max || kv.Int64() < js_limit_min {
kv.VType = 0
Copy link
Member

Choose a reason for hiding this comment

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

this needs to go into temp variable above the switch, must not change (in place) the input data

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I could not get why this change is required. If we move this if
if kv.Int64() > jsMaxSafeInteger || kv.Int64() < jsMinSafeInteger {
kv.VType = model.StringType
value = fmt.Sprintf("%d", value)
}
before switch, the switch case model.StringType will be executed and the previous value will be overwriiten.

Copy link
Member

Choose a reason for hiding this comment

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

You should not be changing the type at all, just the value to be a string.

Comment on lines 27 to 28
js_limit_max = 9007199254740991
js_limit_min = -9007199254740991
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
js_limit_max = 9007199254740991
js_limit_min = -9007199254740991
jsMaxSafeInteger = int64(1)<<53 - 1
jsMinSafeInteger = -jsMaxSafeInteger

{
"key":"javascript_limit",
"vType":"INT64",
"vInt64":9223372036854775222
Copy link
Member

Choose a reason for hiding this comment

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

I expect this to be string, otherwise it will lose precision upon parsing in JS

Suggested change
"vInt64":9223372036854775222
"vInt64":"9223372036854775222"

Copy link
Member

Choose a reason for hiding this comment

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

const z = Number.parseInt("9007199254740993");
console.log(z);
// expected output: 9007199254740992

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes it was shown as a string in ui_01-actual.json . There is a type mismatch between domain_01.json (int64) and ui_01-actual.json (string) and hence the test case TestFromDomain was failing

Copy link
Member

Choose a reason for hiding this comment

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

I am not talking about vType field, it should indeed remain INT64, but the value of vInt64 field needs to be a string, not a raw number, because the raw number is what's causing the precision loss.

@yurishkuro
Copy link
Member

please make sure commits are signed (git commit -s), see CONTRIBUTING.md

Copy link
Member

@yurishkuro yurishkuro left a comment

Choose a reason for hiding this comment

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

You still have some commits unsigned. I recommend squashing them into one commit that you can sign.

{
"key":"javascript_limit",
"vType":"INT64",
"vInt64":9223372036854775222
Copy link
Member

Choose a reason for hiding this comment

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

I am not talking about vType field, it should indeed remain INT64, but the value of vInt64 field needs to be a string, not a raw number, because the raw number is what's causing the precision loss.

@@ -122,6 +128,10 @@ func (fd fromDomain) convertKeyValues(keyValues model.KeyValues) []json.KeyValue
value = kv.Bool()
case model.Int64Type:
value = kv.Int64()
if kv.Int64() > js_limit_max || kv.Int64() < js_limit_min {
kv.VType = 0
Copy link
Member

Choose a reason for hiding this comment

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

You should not be changing the type at all, just the value to be a string.

@@ -122,6 +128,10 @@ func (fd fromDomain) convertKeyValues(keyValues model.KeyValues) []json.KeyValue
value = kv.Bool()
case model.Int64Type:
value = kv.Int64()
if kv.Int64() > jsMaxSafeInteger || kv.Int64() < jsMinSafeInteger {
kv.VType = 0
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
kv.VType = 0

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have done the required changes. Could you please review?

shubbham1215 and others added 7 commits November 9, 2022 01:02
 [Bug]: span tags of type int64 may lose precision jaegertracing#3958

Signed-off-by: Shubham Sawaiker <[email protected]>
Bumps [github.com/spf13/viper](https://github.com/spf13/viper) from 1.13.0 to 1.14.0.
- [Release notes](https://github.com/spf13/viper/releases)
- [Commits](spf13/viper@v1.13.0...v1.14.0)

---
updated-dependencies:
- dependency-name: github.com/spf13/viper
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: Shubham Sawaiker <[email protected]>
…tracing#4026)

Bumps [github.com/dgraph-io/badger/v3](https://github.com/dgraph-io/badger) from 3.2103.3 to 3.2103.4.
- [Release notes](https://github.com/dgraph-io/badger/releases)
- [Changelog](https://github.com/dgraph-io/badger/blob/main/CHANGELOG.md)
- [Commits](dgraph-io/badger@v3.2103.3...v3.2103.4)

---
updated-dependencies:
- dependency-name: github.com/dgraph-io/badger/v3
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: Shubham Sawaiker <[email protected]>
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 2.1.29 to 2.1.31.
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@ec3cf9c...c3b6fce)

---
updated-dependencies:
- dependency-name: github/codeql-action
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: Shubham Sawaiker <[email protected]>
Bumps [anchore/sbom-action](https://github.com/anchore/sbom-action) from 0.13.0 to 0.13.1.
- [Release notes](https://github.com/anchore/sbom-action/releases)
- [Commits](anchore/sbom-action@b7e8507...06e1094)

---
updated-dependencies:
- dependency-name: anchore/sbom-action
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: Shubham Sawaiker <[email protected]>
@shubbham1215 shubbham1215 marked this pull request as ready for review November 8, 2022 20:00
switch kv.VType {
case model.StringType:
value = kv.VStr
case model.BoolType:
value = kv.Bool()
case model.Int64Type:
value = kv.Int64()
if jsflag {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
if jsflag {
if kv.Int64() > jsMaxSafeInteger || kv.Int64() < jsMinSafeInteger {

Comment on lines 124 to 127
var jsflag bool = false
if kv.Int64() > jsMaxSafeInteger || kv.Int64() < jsMinSafeInteger {
jsflag = true
}
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
var jsflag bool = false
if kv.Int64() > jsMaxSafeInteger || kv.Int64() < jsMinSafeInteger {
jsflag = true
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Commited

@codecov
Copy link

codecov bot commented Nov 8, 2022

Codecov Report

Base: 97.18% // Head: 97.16% // Decreases project coverage by -0.02% ⚠️

Coverage data is based on head (1a845ba) compared to base (84c0abc).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4023      +/-   ##
==========================================
- Coverage   97.18%   97.16%   -0.03%     
==========================================
  Files         295      295              
  Lines       17390    17393       +3     
==========================================
- Hits        16901    16900       -1     
- Misses        394      397       +3     
- Partials       95       96       +1     
Flag Coverage Δ
unittests 97.16% <100.00%> (-0.03%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
model/converter/json/from_domain.go 100.00% <100.00%> (ø)
plugin/storage/badger/spanstore/reader.go 95.49% <0.00%> (-0.72%) ⬇️
plugin/storage/integration/integration.go 75.95% <0.00%> (-0.39%) ⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[Bug]: span tags of type int64 may lose precision
@yurishkuro yurishkuro enabled auto-merge (squash) November 8, 2022 20:58
@yurishkuro
Copy link
Member

Thanks!

@shubbham1215
Copy link
Contributor Author

Do I need to make more changes? I saw that some tests related to docker are failing.

@yurishkuro
Copy link
Member

probably spurious failures. I have the auto-merge enabled, will keep an eye on the CI

@yurishkuro
Copy link
Member

ah, I just realized the issue - your PR is opened from the main branch of your fork, this is why the CI is failing. Please create another branch and open a new PR.

@yurishkuro
Copy link
Member

replaced by #4034

@yurishkuro yurishkuro closed this Nov 9, 2022
auto-merge was automatically disabled November 9, 2022 20:36

Pull request was closed

yurishkuro pushed a commit that referenced this pull request Nov 9, 2022
### Avoid value precision loss

Signed-off-by: Shubham Sawaiker
[[email protected]](mailto:[email protected])


  ###  Which problem is this PR solving?

-   Resolves:  #3958

### Short description of the changes

- avoid display value precision loss in case of value overflow
Number.MAX_VALUE

Previous PR was made from main branch because of which CI jobs were
failing.
First PR link : #4023

Signed-off-by: Shubham Sawaiker <[email protected]>
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: span tags of type int64 may lose precision
2 participants