feat(openapi): Int64String codec for 64-bit ids over JSON#12
Merged
Conversation
…cases Address PR review of the Int64String codec: - StringifyIntParam now panics (wrapping ErrUndefined) when the named property is absent, matching the panic-on-unknown-name convention of the other openapi accessors. A silent no-op could leave a 64-bit id advertised as `integer` after a param rename/typo — silently reintroducing the exact float64 truncation this type prevents. - Preserve the property's Title (not just Description) on rewrite; document that integer-only keywords (minimum, format, …) are intentionally dropped. - Clarify that int64StringPattern is an advisory client hint and ParseInt is the authoritative gate (accepts leading '+', enforces the int64 range the regex cannot express). - Tests: reject overflow (int64 bounds ±1) matching-the-pattern-but-not-the decoder; round-trip MaxInt64/MinInt64/negative/zero; reject a small bare number (guard is unconditional, not range-driven); assert Title preservation and the absent-name panic. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Drop the dead bytes.TrimSpace and manual quote guard in UnmarshalJSON; json.Unmarshal into a string already rejects bare numbers and non-string JSON, and the SDK strips surrounding whitespace before the call. Removes the bytes import. Fold positive bigID into the round-trip table and delete two tests it subsumes (MarshalEmitsQuotedString, RoundTripIsIdentity).
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
1 participant
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
64-bit ids (e.g. Alor order ids ~2e18) exceed float64's exact-integer range
(2^53 ≈ 9e15). A JavaScript-based MCP host parses a JSON number into a
float64, truncating the low digits before the value reaches the Go server.
The standard fix (protobuf JSON, Stripe, Twitter snowflake) is to carry 64-bit
ids as JSON strings.
What
New in
openapi:Int64String— anint64that round-trips through JSON as a quoteddecimal string. Decode is string-only and rejects bare numbers (a number
is already truncated by the time we see it — failing loud beats acting on the
wrong id).
MarshalJSONemits the quoted form;Int64()accessor.Int64StringSchema(desc)— the matching input schema(
{type: string, pattern: ^-?[0-9]+$}), preserving the description.StringifyIntParam(schema, name)— rewrites an already-assembled objectschema's integer id property to the string form; no-op if absent.
Tests
8 new unit tests: exact
2011734313187604080round-trip, rejection of barenumbers / null / non-integer strings, schema shape, param rewrite. Suite green
(130), lint clean.
First consumer:
alormcp(fixesorderId/stopOrderIdtruncation onreplace/cancel).
🤖 Generated with Claude Code