Not being connected to the internet results in a crash

[gwaub]

The issue:

Launching umu-run offline (after the initial setup) crashes the program.
Setting UMU_RUNTIME_UPDATE=0 successfully works around it.

Error -2 (Name or service not known) seems to be left unhandled in umu_run.py.

Possible solution:

In umu/umu_run.py (main), change

if e.errno != -3 and e.errno != ENETUNREACH:

to

if e.errno != -2 and e.errno != -3 and e.errno != ENETUNREACH:

I tested both 1.1.2 and latest git on Arch Linux (Kernel 6.6.56-1-lts, Python 3.12.7).

Traceback (most recent call last):
  File "/usr/bin/umu-run", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/usr/lib/python3.12/site-packages/umu/__main__.py", line 9, in main
    return umu_run()
           ^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/umu/umu_run.py", line 789, in main
    future.result()
  File "/usr/lib/python3.12/concurrent/futures/_base.py", line 449, in result
    return self.__get_result()
           ^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/concurrent/futures/_base.py", line 401, in __get_result
    raise self._exception
  File "/usr/lib/python3.12/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/umu/umu_runtime.py", line 213, in setup_umu
    _update_umu(local, json, thread_pool, client_session)
  File "/usr/lib/python3.12/site-packages/umu/umu_runtime.py", line 332, in _update_umu
    client_session.request("GET", url)
  File "/usr/lib/python3.12/http/client.py", line 1336, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3.12/http/client.py", line 1382, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.12/http/client.py", line 1331, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.12/http/client.py", line 1091, in _send_output
    self.send(msg)
  File "/usr/lib/python3.12/http/client.py", line 1035, in send
    self.connect()
  File "/usr/lib/python3.12/http/client.py", line 1470, in connect
    super().connect()
  File "/usr/lib/python3.12/http/client.py", line 1001, in connect
    self.sock = self._create_connection(
                ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/socket.py", line 841, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/socket.py", line 976, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
socket.gaierror: [Errno -2] Name or service not known

[R1kaB3rN]

Thanks for reporting this.

Do you mind retesting at #235. If possible, under the same network conditions.

[R1kaB3rN]

To be clear, I cannot reproduce this on my end, and it's not really clear to me how we can create reliable and reproducible tests in the CI to reproduce all network-related errors.

Not really a fan of blindly catching all socket address-related errors like this either. Instead, I believe the most robust and decisive solution to handle all class of network-related cases like this would be to use an external network library (e.g., requests, httpx). They would handle it better, are better tested, and would save us a lot of code.

See #134 for related issue.

[gwaub]

Can confirm that with #235 applied, umu-run doesn't crash anymore when offline.

This is what gets printed now on stdout:

ERROR: [Errno -2] Name or service not known
Traceback (most recent call last):
  File "/usr/lib/python3.12/site-packages/umu/umu_run.py", line 789, in main
    future.result()
  File "/usr/lib/python3.12/concurrent/futures/_base.py", line 449, in result
    return self.__get_result()
           ^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/concurrent/futures/_base.py", line 401, in __get_result
    raise self._exception
  File "/usr/lib/python3.12/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/umu/umu_runtime.py", line 213, in setup_umu
    _update_umu(local, json, thread_pool, client_session)
  File "/usr/lib/python3.12/site-packages/umu/umu_runtime.py", line 332, in _update_umu
    client_session.request("GET", url)
  File "/usr/lib/python3.12/http/client.py", line 1336, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3.12/http/client.py", line 1382, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.12/http/client.py", line 1331, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.12/http/client.py", line 1091, in _send_output
    self.send(msg)
  File "/usr/lib/python3.12/http/client.py", line 1035, in send
    self.connect()
  File "/usr/lib/python3.12/http/client.py", line 1470, in connect
    super().connect()
  File "/usr/lib/python3.12/http/client.py", line 1001, in connect
    self.sock = self._create_connection(
                ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/socket.py", line 841, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/socket.py", line 976, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
socket.gaierror: [Errno -2] Name or service not known

[R1kaB3rN]

Yeah, that's both expected and intended. I don't want errors like that to pass silently as I cannot reproduce them in my end. Furthermore, I think knowing the error details may be helpful for debugging purposes in the future until we use an external network library for more robust handling of them.

[R1kaB3rN]

Going to go ahead and merge the fix as you're able to launch your game now.

The point is that users with your network conditions will be able to run their game now. If you think I'm wrong and umu-launcher is better off suppressing that error instead, I would like to know why and you'll need to make a PR for it too.

And in the future, more robust handling of network-related errors will be implemented.