Description of problem: The ID certificate serial number is a long (64-bits). It gets serialized into JSON, and returned to the client. The client may deserialize this into a double, which can only have an int up to 53-bits long before precision gets lost. This is a problem because some tools and libraries, most notably any modern browser, node.js, jq, and probably more, will load numerical values not as a long, but as a double, and the serial number is now incorrect. Since it is entirely possible for a javascript client to exist which would handle consumer payloads, the ID certificate serial number should either: - fit in 53-bits - be a string And if we're changing the "serial" value, we should change the "id" value too, since they both are equal, from what I see. How reproducible: Always Steps to Reproduce: 1. Get any consumer from candlepin, which should include the id-cert serial number. 2. Grab the id-cert serial number. Here's an example one: 2549664266108101582 3. Open your browser's developer tools window (ctrl+shift+I) 4. Paste this into the console prompt: JSON.stringify(JSON.parse('{"idCert": {"serial": {"id": 2549664266108101582}}}')); Actual results: You get this output: {"idCert":{"serial":{"id":2549664266108101600}}} Expected results: Well, that's the thing, is this is expected since we're treating the serial as a number, rather than as a string. If it were a string, we wouldn't worry about precision loss.
Al, we wanted your thoughts on this one...
Yeah, providing it as a string in the JSON response seems reasonable to me. It may be tricky with Jackson though since I imagine we will still want it to be a long internally but we'll need to tell Jackson to serialize it as a string. We'll also need to look through subscription-manager and see where/how it uses the serial. My instinct is that subscription-manager will be agnostic toward the data type. Nice catch, Shayne.
Thank you for your interest in Candlepin. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the project, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this feel free to open a new bug with more up to date details. Thank you.