Fix int64 precision loss in JSON loader#5494
Merged
Merged
Conversation
JSON numbers were decoded as float64, which corrupts integer values above 2^53 (job, run, and pipeline IDs routinely exceed this). Enable json.Number decoding and parse integer literals as int64; literals with a fraction or exponent stay float64. Co-authored-by: Isaac
Collaborator
Integration test reportCommit: a2ec435
28 interesting tests: 15 SKIP, 7 KNOWN, 6 flaky
Top 50 slowest tests (at least 2 minutes):
|
Co-authored-by: Isaac
janniklasrose
approved these changes
Jun 12, 2026
Collaborator
Integration test reportCommit: 983a9b0
415 interesting tests: 352 MISS, 26 RECOVERED, 21 FAIL, 8 KNOWN, 3 PANIC, 3 flaky, 2 SKIP
Top 50 slowest tests (at least 2 minutes):
|
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
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.
Why
Found during a full-repo review of the CLI. The JSON loader decodes every number as float64, which has a 53-bit mantissa. Integer values above 2^53 silently lose precision, and job, run, and pipeline IDs routinely exceed that. For example,
--json '{"job_id": 123456789012345678}'unmarshals to123456789012345680and targets the wrong resource. The corruption happens at load time, so the precision guard inconvert.Normalizenever sees the original value.Changes
Before, all JSON numbers became float64; now integer literals are loaded as int64 and keep their exact value. The loader in
libs/dyn/jsonloader/json.goenablesdecoder.UseNumber()and handles thejson.Numbertoken: integer literals parse as int64, while literals with a fraction or exponent (2.0,1e3) stay float64. Integer literals that overflow int64 also fall back to float64, matching the previous decoder behavior.This affects everything loading through
jsonloader: the--jsonflag on generated commands and bundle variable files. Both paths normalize values against the target type afterwards, andconvert.Normalizealready converts int to float (and back) with precision checks, so well-formed inputs are unaffected apart from no longer being corrupted.Test plan
libs/dyn/jsonloader: large positive and negative int64 values, max int64, floats with fraction or exponent, int64 overflow fallback, out-of-range error, and a mixed object converted viaconvert.ToTypedasserting the exact job IDgo test ./libs/dyn/...go test ./libs/flags ./bundle/config/mutator(the twoLoadJSONconsumers)bundle/variables/file-defaults,cmd/workspace/apps,cmd/workspace/database/update-database-instance./task fmt-q,./task lint-q,./task checksThis pull request and its description were written by Isaac.