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 involved.

In Koji 1.14, we started accepting and returning i8 tags, an extension to the xmlrpc standard.

https://docs.pagure.org/fork/mikem/koji/release_notes_1.14/#large-integer-support
https://pagure.io/koji/pull-request/571

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:

https://pagure.io/koji/issue/750

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.

So...

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.