Waiting time should be limited

[blokhin]

Currently, in case of some errors, this waits forever, and the synchronous client hangs on:

  ...
  File "/home/eb/metis-client/lib/python3.8/site-packages/asgiref/sync.py", line 218, in __call__
    current_executor.run_until_future(loop_future)
  File "/home/eb/metis-client/lib/python3.8/site-packages/asgiref/current_thread_executor.py", line 59, in run_until_future
    work_item = self._work_queue.get()
  File "/usr/lib/python3.8/queue.py", line 170, in get
    self.not_empty.wait()
  File "/usr/lib/python3.8/threading.py", line 302, in wait
    waiter.acquire()

Probably, some timer should be presented.

[blokhin]

to reproduce, e.g. stop BFF during the test run of client... it waits forever...

[blokhin]

Wow, I have also discovered it might influence the GUI for that particular user 😳

this happens only when our script hangs... As soon as we stop the script, GUI starts to work normally. Obviously, BFF works.

[blokhin]

As noted by @knopki the asynchronous code supports the timeout straight away:

async with asyncio.timeout(5):
    await long_running_task()

However, a timeout argument is required for the synchronous code (may default to e.g. 5 seconds)

[blokhin]

@knopki please, let’s prioritise this 🙏

[knopki]

Wow, I have also discovered it might influence the GUI for that particular user flushed
this happens only when our script hangs... As soon as we stop the script, GUI starts to work normally. Obviously, BFF works.

I can't confirm that.
If BFF dies because of some error, then yes, metis-client might influence the GUI.
But if the synchronous client is just waiting for results, the GUI works just fine.
Therefore, if there is a bug here, it's on the BFF side.

Timeouts as a client feature are implemented in #23