You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cause:
The worker calls finish_task() over XML-RPC each 90 seconds again if the previous call does not finish till then. This is caused by retry_request_decorator:
I guess the XML-RPC connection times out after 60 seconds, then the decorator sleeps for 30 seconds. The messages from kobo can be seen at the and of stdout.log (rather than in worker.log where I looked for them initially). I think we need to distinguish network-related timeouts from the time actually spent by a remote operation.
It is also a bad idea to repeat an XML-RPC call that has already been (at least partially) handled by the remote service.
As figured out by @lzaoral, this is a regression introduced by #173.
The text was updated successfully, but these errors were encountered:
I am forwarding an issue from Red Hat internal Jira that I was debugging in June 2024 but that I have not resolved yet.
Current Behavior:
If the scan results tarball is too big, the OSH task ends up in the INTERRUPTED state despite it was successful:
Expected Behavior:
The task status remains CLOSED.
Impact Statement:
Scan results are successfully uploaded and unpacked. Only the task status is misleading.
worker.log
contains:hub.log
contains:Cause:
The worker
calls finish_task()
over XML-RPC each 90 seconds again if the previous call does not finish till then. This is caused byretry_request_decorator
:kobo/kobo/xmlrpc.py
Line 462 in 1ac4034
I guess the XML-RPC connection times out after 60 seconds, then the decorator sleeps for 30 seconds. The messages from kobo can be seen at the and of
stdout.log
(rather than inworker.log
where I looked for them initially). I think we need to distinguish network-related timeouts from the time actually spent by a remote operation.It is also a bad idea to repeat an XML-RPC call that has already been (at least partially) handled by the remote service.
As figured out by @lzaoral, this is a regression introduced by #173.
The text was updated successfully, but these errors were encountered: