Fix float precision loss in jsonschema ParseFloat#4992
Open
Conversation
denik
force-pushed
the
denik/random-bugfixes-3
branch
3 times, most recently
from
6ffc4be to
b6f655c
Compare
pietern
approved these changes
Apr 22, 2026
strconv.ParseFloat(s, 32) parses the string as a float32 and then promotes it to float64, silently losing precision. For example, "1.1" becomes 1.100000023841858 instead of 1.1. This affects users who specify number-type template variables during `databricks bundle init`. Change the bit size from 32 to 64 to preserve full float64 precision. Task: 001.md Co-authored-by: Isaac
Co-authored-by: Isaac
Adds an acceptance test that renders a template with a number-type variable (default 1.1). Prior to the ParseFloat bit-size fix the value rendered as 1.100000023841858; with the fix it renders as 1.1. Task: 005.md Co-authored-by: Isaac
The lint check originally failed with 'parallel golangci-lint is running', caused by concurrent worktrees colliding on the shared /tmp lockfile. Restore allow-parallel-runners: true in .golangci.yaml. After unblocking, testifylint's float-compare also flagged two assert.Equal calls in libs/jsonschema/utils_test.go (introduced by the float precision fix). Switch to assert.InDelta with delta=0 to express exact equality and satisfy the linter. Task: 006.md Co-authored-by: Isaac
Drop the unrelated allow-parallel-runners restoration in .golangci.yaml that was bundled into 2b6721afc. The parallel-runner setting is an environment-only workaround (per-worktree TMPDIR is the durable fix, tracked separately) and adding it here violates the repo's one-change per-PR rule. With the lint config no longer enabling testifylint's float-compare across this branch, reword the two affected assertions to use assert.Equal directly with an inline nolint:testifylint comment that documents why exact float64 equality is the property under test. Task: 007.md Co-authored-by: Isaac
denik
force-pushed
the
denik/random-bugfixes-3
branch
from
b6f655c to
1da53a5
Compare
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.
Changes
ParseFloatto use 64-bit precision instead of 32-bit, which caused silent precision loss for float values inbundle inittemplate prompts (e.g.,1.1became1.100000023841858).Tests