- Shipped
- 15 Agosti 2026, 19:58 UTC
- Author
- Kamo
- Commit
- 88519a3
CockroachDB unique_rowid() ids are 19 digits, past Number.MAX_SAFE_INTEGER, so an id sent as a JSON number arrives in the browser with its low digits rounded away and every lookup made with it misses. 163 handler responses put raw Long org and member ids into ad-hoc Maps, so this was not something DTO-by-DTO work could close. The reason it stayed open is that the obvious fix takes the platform down. The mapper that serves responses is the same bean KSessionService writes the *** session map to Redis with, and ids are read back out of that map by ((Number) ...).longValue() -- 65 times in this service, and again in DocsService, MediaService and ConversionService, which read the same payload. Quote Long on that bean and every one of those throws. So the rule is attached to the MVC message converters instead, on a copy. Responses get it; sessions, NATS publishers and the service-to-service clients keep the numeric mapper they have always had. It is also not a blanket Long -> String. Long is not a synonym for id here: epoch millis on SecurityRoleDTO and the branch-type and security-model DTOs, LeadIntakeEndpointDTO's counters, Page.getTotalElements(), byte sizes and durations are all Longs the browser does arithmetic and new Date() on, and most arrive inside Maps where a mix-in has no key to attach to. The serializer switches on value instead: above the JS safe range it writes a string, below it a number. Every unique_rowid is above, every timestamp, count and size is below, and fields nobody has classified yet are handled by the same rule. Verified against the peers that read these responses: KamoJwtService and DavAuthFilter already accept either form (instanceof Number ? ... : Long.parseLong(...)).