Fix precision loss for large integers in query results#7645
Open
nmosafi wants to merge 5 commits intogetredash:masterfrom
Open
Fix precision loss for large integers in query results#7645nmosafi wants to merge 5 commits intogetredash:masterfrom
nmosafi wants to merge 5 commits intogetredash:masterfrom
Conversation
Integers exceeding JavaScript's Number.MAX_SAFE_INTEGER (2^53-1) are converted to strings during JSON serialization to preserve their exact values. The backend column type stays "integer" so the frontend can still treat the column as numeric for display purposes. On the frontend, the type-sniffing logic now recognises string values that represent large integers in "integer" columns and skips re-typing them as "string". The number formatter also guards against converting such strings back to JavaScript Numbers via numeral. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
The round-trip check (String(Number(value)) !== value) missed values that are exactly representable as float64 but still exceed MAX_SAFE_INTEGER. The numeral library's internal arithmetic can introduce drift for these values (e.g. 1772031600000261600 formatted as 1,772,031,600,000,261,632). Use Number.isSafeInteger() instead, which correctly catches all integers beyond 2^53-1. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
10 tasks
Contributor
|
I see this as a valid issue. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Number.MAX_SAFE_INTEGER(2^53 - 1) lose precision when parsed byJSON.parse()in the browser. For example, a bigint value of1771858801316128013would display as1771858801316128000.json_dumpsnow converts unsafe integers to strings during serialization, preserving their exact values. The column type remains"integer"so the frontend can still treat the column as numeric for display purposes.query-result.jsnow recognises string values that represent large integers in"integer"columns and skips re-typing them as"string".value-format.tsxguards against converting such strings back to JavaScript Numbers via thenumerallibrary.Test plan
tests/utils/test_json_dumps.py)BIGINT) display exact values in table visualizationMAX_SAFE_INTEGER) are unaffected🤖 Generated with Claude Code