koji

#750 Drop use of encode_int on hub
Closed: Fixed Opened by mikem.

Closed: Fixed
Reopen Issue

When we added large integer support in the 1.14 release, we kept around some old code that worked around large integers in targeted ways, via the encode_int and decode_int functions. This older code would convert large integers to strings in a few targeted places. We left it to avoid changing the api in an incompatible way.

In the old way:

  • encode_int() is used a few places on the hub for some file size and offset values
  • decode_int() is used on the offset and size parameters in the uploadFile method (this is the older upload pathway)
  • encode_int() is also used in kojikamid for the offset value when fetching a file from outside via the kojivmd getFile handler

The goal of this issue is only to remove the first part (encode_int use on the hub).

This is an api change, thought a relatively minor one. When we make this change, these large integers will instead be encoded with i8 tags. However, we are already returning i8 tags in other places. For any clients using python, the change should be transparent, since the python lib understands i8.

Other xmlrpc clients may have trouble. For that reason, I'm targeting this at least one release out in the hopes that we can have some conversation and data-gathering first.

Metadata Update from @mikem:
- Issue set to the milestone: 1.17

Why leave the other two? Well...

  • Leaving the decode_int() in the old upload code in case an old client is still sending that way. It's harmless to accept both here
  • leaving the kojikamid code alone because it is an isolated special case

If you have concerns about this change, please raise them here or on the mailing list

I would like to drop also decode_int and just use int() conversion in those two places in hub. This function call has almost same cost and behaviour as calling int() directly even on int objects.

PR #852

Metadata Update from @tkopecek:
- Issue tagged with: easyfix

Metadata Update from @tkopecek:
- Issue tagged with: deprecation

Thanks for the heads' up. I grepped around a couple non-Python clients.

The Jenkins Koji plugin uses org.apache.xmlrpc, and this supports <i8>

RH's Errata Tool uses the xmlrpc Ruby gem, and that supports <i8> as of Ruby 2.0.0.

The kojiji library uses a Java lib "RWX", and this does not have support for <i8> that I can tell. I've filed https://github.com/release-engineering/kojiji/issues/98 for this.

RWX has PR under review now: https://github.com/Commonjava/RWX/pull/33, However as kojiji/RWX don't support i8 now, they could be already hit some problems now.

note: the RWX pr above has been merged, and the corresponding issue closed.

Commit 088d500e fixes this issue

Commit f4ee1500 fixes this issue

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/750

Please continue any further discussion there.
Metadata
None

deprecation easyfix

None
None
Low
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.