koji

#2668 TypeError in _callMethod()'s max_tries conditional
Closed: Fixed by tkopecek. Opened by ktdreyer.

Closed: Fixed
Reopen Issue

When our Koji instance was unavailable, a koji-ansible user hit the following stack trace when calling session.getTag():

File "/usr/lib/python3.7/site-packages/koji/__init__.py", line 2135, in __call__
    return self.__func(self.__name, args, opts)
  File "/usr/lib/python3.7/site-packages/koji/__init__.py", line 2671, in _callMethod
    if tries > max_retries:
TypeError: '>' not supported between instances of 'int' and 'NoneType'

I'm not sure which variable was None, but I guess we need to handle that.

Oh, I read further up in the logs, and we actually raised the real error here:

raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='koji.example.com', port=443): Max retries exceeded with url: /brewhub (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f23f3c30750>: Failed to establish a new connection: [Errno 110] Connection timed out'))
During handling of the above exception, another exception occurred...

It would be great to only raise the main error so it's easier for users and developers to understand the nature of the problem.

Metadata Update from @tkopecek:
- Custom field Size adjusted to None
- Issue set to the milestone: 1.25
- Issue tagged with: bug

Problem is introduced by incorrectly set default value PR #2689 should fix it.

Metadata Update from @jcupova:
- Issue tagged with: testing-ready

Metadata Update from @mfilip:
- Issue tagged with: testing-done

Commit eb644e7e fixes this issue

Commit 32929a79 fixes this issue

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

Please continue any further discussion there.
Metadata
None

bug testing-done testing-ready

None
None
Low
None
Related Pull Requests
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.