fix(apiquery): preserve narrow numeric parameters - #76
Open
sylvesterkaczmarek wants to merge 2 commits into
Open
fix(apiquery): preserve narrow numeric parameters#76sylvesterkaczmarek wants to merge 2 commits into
sylvesterkaczmarek wants to merge 2 commits into
Conversation
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.
Summary
Preserve narrow Go numeric values when encoding URL query parameters.
Fixes #75.
Problem
internal/apiquerycurrently has two width-related serialization gaps:int8anduint8are not included in the primitive integer cases, so they silently produce no query pair;float32shares thefloat64formatting path and is passed tostrconv.FormatFloatwithbitSize=64, exposing precision introduced only when reflection widens the value to a Gofloat64.A caller can therefore omit a legitimate numeric query parameter entirely, or send a decimal representation different from the source
float32value.Reproduction
On upstream
mainatd082a010f7c6cacf407d8a1581446a7857f9f1bb:Root cause
The primitive switch omitted the 8-bit integer kinds and grouped both floating-point kinds behind:
reflect.Value.Float()returns afloat64, butFormatFloat'sbitSizeargument is specifically what tells it whether the original value should be represented with 32-bit or 64-bit precision.The sibling multipart/form encoder already follows that distinction for primitive values.
Fix
reflect.Int8with the signed integer kinds;reflect.Uint8with the unsigned integer kinds;reflect.Float32withbitSize=32;bitSize=64forreflect.Float64.No query key formatting, array formatting, nesting rules, null handling, or existing wider numeric behavior changes.
Regression coverage
Extended the existing table-driven
TestEncodecases with:int8(-8)->query=-8;uint8(8)->query=8;float32(0.1)->query=0.1.These cases fail on current
mainfor the reasons described above and exercise the realMarshalWithSettingspath rather than an isolated helper.Validation
The branch is based directly on current upstream
mainand is not behind it. The diff is limited to:internal/apiquery/encoder.go;internal/apiquery/query_test.go.Full repository validation is left to the repository's GitHub Actions checks.
Risk
Low. The change only fills missing primitive cases and uses the source floating-point width when choosing the standard-library formatting precision. Existing
int, wider integer, andfloat64output is unchanged.