- Shipped
- August 27, 2026 at 3:42 PM UTC
- Author
- Kamo
- Commit
- ddab3e3
`commerce_vendors.uid` is `INT8 DEFAULT unique_rowid()` -- about 19 digits, where `Number.MAX_SAFE_INTEGER` has sixteen. A numeric id of that size is an IEEE-754 double in a browser and `JSON.parse` rounds it before any client code runs, so the id names a vendor that does not exist and the picker that engages a vendor on a work order engages nobody, with a 400 that reads like a bug in the tab. Nothing throws on either side. SecurityService already quoted an out-of-range `Long` on the way out -- `JsSafeLongSerializer`, scoped to the MVC message converters by `HttpWireJacksonConfig`, deliberately not global because registering it on the shared mapper stringifies the *** session ids and answers 401 platform-wide. So a real vendor id did reach the browser intact. What that serializer cannot give is a *stable* type: its rule is by value, so a 19-digit id was a JSON string and a hand-seeded 3-digit one a JSON number, on the same field, in the same response. `posApi.Vendor` declared `uid: number` and was wrong about production rows and right about test rows, which is the worst of both. So `VendorDTO` types its three ids `String` and `toVendorDTO` stringifies them, the rule `ServiceJobApi` and `ServiceTaskBookApi` already state. The answer is now the same for every row and every value, which is what lets a client declare the field at all. `idOrNull` keeps an absent id null rather than sending the four characters "null", which a bare `String.valueOf` would. `Vendor.uid` stays a `Long` primary key and `POSController`'s `@PathVariable Long id` still binds -- Spring converts the quoted integer exactly as it converted the bare one. This is a wire-format change, no DDL. `VendorWireContractTest` pins it, including the half a value-range serializer gets wrong: a *small* id is quoted too.