agent's JSON encoder lost precision on 64-bit IDs - JavaScript numbers rounded the IDs and lookups returned the wrong...
Keeps 64-bit IDs exact through JSON as strings or BigInt. Use when large-ID lookups return wrong records. Not for small IDs.
TL;DR
The agent's JSON encoder used JavaScript numbers for 64-bit IDs, rounding them, so lookups returned the wrong records. Serialize large IDs as strings (or use BigInt) end to end.
Error
lookup for id 9007199254740993 returned the record for 9007199254740992Steps
- Confirm the IDs exceed 2^53 - 1 Expected: you confirm precision loss is possible.
- Serialize IDs as strings in requests and parse them as strings/BigInt in responses Expected: no rounding.
- Check the whole path: encoder, transport, decoder, storage Expected: no step coerces to float.
- Add a test with an ID above 2^53 asserting round-trip equality Expected: it cannot regress.
When to use
- Wrong records returned for large IDs
- The JSON layer uses float64 numbers
When not to use
- IDs are small (then the bug is elsewhere)
- The API itself rounds (then it is a provider bug; send as string anyway)
Tool compatibility
- 64-bit integer JSON handling
- JavaScript clients
Variant phrasings
id rounding wrong record
IDs above 2^53 lose precision as JSON numbers. Use strings or BigInt.
large id lookup wrong
Same: float64 cannot hold 64-bit IDs exactly.
Why it happens
JSON has one number type and JS implements it as float64. Agents learn this the hard way because small test IDs never trigger it.
Edge cases
- Databases and queues in the path must also keep the ID as string/BigInt
- String IDs sort lexicographically; do not rely on numeric sort
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_3ijPeKRHU3lDxicP3R62Mw