tl;dr -- if your Koji client code can't handle i8 tags, please speak up!
The baseline xmlrpc standard only supports 32bit signed integers. This has
been a problem for Koji over the years. Early on, we performed some
targeted string conversion on integers over the limit in the few places the
kept cropping up (file sizes generally). This worked using the encode_int
and decode_int functions. For users of the Koji python lib, things just
worked. Other users had to do a little more work if large ints were
In Koji 1.14, we started accepting and returning i8 tags, an extension to
the xmlrpc standard.
This was a much better approach. However, it did require that clients
understand the i8 tag. We knew that Python's xmlrpc lib did. However, we
weren't sure how broadly this extension was implemented elsewhere.
Because we weren't sure, we left the existing targeted string conversions
on the hub side alone. We filed this bug to track its eventual removal:
At this point, we're considering removing those workarounds and letting the
code just use the i8 tags for all our large ints. However, we don't want to
suddenly break any non-python code that is interacting with a Koji instance.
Do you have code that will break if the hub returns an i8 tag?
If so, how much work would it be to fix that?
Please comment on Issue 750 with your concerns.