Some proxys turn out to be NoneType after some time

[nikromen]

package_proxy from client is used in packit's wait-for-copr script.

There's package_proxy used in the loop and perhaps in case of network error it changes itself to None (?!, PackageProxy is initialized once when calling Client, it shouldn't change itself randomly to None) even though there is a check in the script that package_proxy is not None (??!!)

2023-07-18 12:37:55.156 logging.py        INFO   No package with name python-copr-common in copr fedora-copr-copr-2818
2023-07-18 12:38:05.193 logging.py        INFO   No package with name python-copr-common in copr fedora-copr-copr-2818
2023-07-18 12:38:15.235 logging.py        INFO   No package with name python-copr-common in copr fedora-copr-copr-2818
2023-07-18 12:38:25.275 logging.py        INFO   Traceback (most recent call last):
2023-07-18 12:38:25.275 logging.py        INFO     File "/usr/bin/wait-for-copr", line 8, in <module>
2023-07-18 12:38:25.275 logging.py        INFO       sys.exit(wait_for_copr())
2023-07-18 12:38:25.276 logging.py        INFO                ^^^^^^^^^^^^^^^
2023-07-18 12:38:25.276 logging.py        INFO     File "/usr/lib/python3.11/site-packages/click/core.py", line 1130, in __call__
2023-07-18 12:38:25.276 logging.py        INFO       return self.main(*args, **kwargs)
2023-07-18 12:38:25.276 logging.py        INFO              ^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-07-18 12:38:25.276 logging.py        INFO     File "/usr/lib/python3.11/site-packages/click/core.py", line 1055, in main
2023-07-18 12:38:25.276 logging.py        INFO       rv = self.invoke(ctx)
2023-07-18 12:38:25.276 logging.py        INFO            ^^^^^^^^^^^^^^^^
2023-07-18 12:38:25.276 logging.py        INFO     File "/usr/lib/python3.11/site-packages/click/core.py", line 1404, in invoke
2023-07-18 12:38:25.277 logging.py        INFO       return ctx.invoke(self.callback, **ctx.params)
2023-07-18 12:38:25.277 logging.py        INFO              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-07-18 12:38:25.277 logging.py        INFO     File "/usr/lib/python3.11/site-packages/click/core.py", line 760, in invoke
2023-07-18 12:38:25.277 logging.py        INFO       return __callback(*args, **kwargs)
2023-07-18 12:38:25.277 logging.py        INFO              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
2023-07-18 12:38:25.277 logging.py        INFO     File "/usr/lib/python3.11/site-packages/wait_for_copr/__init__.py", line 65, in wait_for_copr
2023-07-18 12:38:25.277 logging.py        INFO       built_version = copr_package_proxy.get(
2023-07-18 12:38:25.277 logging.py        INFO                       ^^^^^^^^^^^^^^^^^^^^^^^
2023-07-18 12:38:25.277 logging.py        INFO   TypeError: 'NoneType' object is not subscriptable

in logs above, the existence of python-copr-common pkg is checked a few times and then randomly the package_proxy happens to be NoneType

logs:
https://download.copr.fedorainfracloud.org/results/packit/fedora-copr-copr-2818/srpm-builds/06182105/builder-live.log.gz

[lsm5]

podman team also hit this issue recently: https://github.com/containers/podman/actions/runs/6247273398/job/16959529269#step:6:16

[praiskup]

That seems different:

   File "/home/runner/.local/lib/python3.10/site-packages/wait_for_copr/__init__.py", line 66, in wait_for_copr
    if release in (built_version := build["source_package"]["version"]):
TypeError: argument of type 'NoneType' is not iterable

The built version becomes None, not the proxy?

[praiskup]

The original failing code is here.

[praiskup]

Aha, I'm better reading the traceback @nikromen posted and TypeError: 'NoneType' object is not subscriptable is actually raised by None[], not None.get() (which would raise AttributeError: 'NoneType' object has no attribute 'get').

So there's not a bug "proxy becomes None". The problem is somewhere with the return value, and @lsm5 is right that these issues have likely the same roots...

[lsm5]

@lsm5 is right that these issues have likely the same roots

TBH, I didn't look too much into it 😄 , only commented cause @nikromen sent me the link and the failure looked similar to what I noticed. Anyway, glad the issues are documented!

[praiskup]

This should be resolved in the latest wait-for-copr script. Please reopen if you still see the problem.