Repository navigation
jsonrpc: decimal and exponent integer IDs still lose precision after #1401 #1404
Description
After #1401 (95591a7), integer-literal request IDs retain their precision, but equivalent decimal/exponent forms still go through the float64 fallback in MakeID.
Reproduction through both DecodeMessage and MakeID(json.Number(...)):
| Input ID | Expected numeric value | Actual |
|---|---|---|
| 9007199254740993 | 9007199254740993 | 9007199254740993 |
| 9007199254740993.0 | 9007199254740993 | 9007199254740992 |
| 90071992547409930e-1 | 9007199254740993 | 9007199254740992 |
| -9007199254740993.0 | -9007199254740993 | -9007199254740992 |
For example, decode {"jsonrpc":"2.0","id":9007199254740993.0,"method":"m"}. The decoded Request.ID.Raw() is 9007199254740992. The same occurs for response decoding.
Cancellation also uses MakeID: an integer request ID of 9007199254740993 does not match notifications/cancelled with requestId 9007199254740993.0 or 90071992547409930e-1.
These values are mathematically integral and within int64. Preserving their numeric value does not require retaining the original decimal spelling. JSON-RPC requires the response ID value to match the request: https://www.jsonrpc.org/specification#request_object.
Proposed scope: keep the integer-literal fast path, then normalize integral decimal/exponent forms exactly without exponent-sized allocations. Preserve the current fallback for genuinely fractional/out-of-range values and the existing float64 API behavior. The stricter rejection policy proposed in #1178 is separate.
Activity
guglielmo-san commentedon Oct 16, 2026
@skosovsky we decided to introduce the fallback to float64 to keep backward compatibility and keep the MakeID() simple. JSON-RPC 2.0 §4 discourages fractional/exponential IDs.
Is this an issue you are actively facing?
skosovsky commentedon Oct 16, 2026
We haven't confirmed these decimal/exponent IDs in production client traffic. We found this through SDK migration and protocol regression tests for our Zalo MCP server. Our current SDK fork already preserves these values exactly, so this is a compatibility gap we need to close before switching back to the upstream SDK, rather than an active production incident.