Remove timeout loop in FluentConnection

[mkundu1]

trying to understand the impact

Looking at how we are launching Fluent from PyFluent, the timeout loop in FluentConnection is unnecessary. I have replaced it with a check_health call which will fail only if there is some issue at grpc communication level and it will expose the grpc error message in that case. Exposing the grpc error message here will help us to triage issues in user's system.

The start_timeout is used only when we wait for the server to finish writing the server-info file.

Tested by hardcoding a port in FluentConnection, so grpc connection will fail due to port-mismatch:
Old behaviour (fails after 60 s):

>>> solver = pyfluent.launch_fluent()
pyfluent.launcher ERROR: Exception caught - RuntimeError: The connection to the Fluent server could not be established within the configurable 60 second time limit.
Traceback (most recent call last):
  File "D:\ANSYSDev\PyFluentDev\pyfluent\src\ansys\fluent\core\launcher\launcher.py", line 750, in launch_fluent
    session = new_session.create_from_server_info_file(
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\ANSYSDev\PyFluentDev\pyfluent\src\ansys\fluent\core\session.py", line 226, in create_from_server_info_file
    fluent_connection=FluentConnection(
                      ^^^^^^^^^^^^^^^^^
  File "D:\ANSYSDev\PyFluentDev\pyfluent\src\ansys\fluent\core\fluent_connection.py", line 283, in __init__
    raise RuntimeError(
RuntimeError: The connection to the Fluent server could not be established within the configurable 60 second time limit.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\ANSYSDev\PyFluentDev\pyfluent\src\ansys\fluent\core\launcher\launcher.py", line 784, in launch_fluent
    raise LaunchFluentError(launch_cmd) from ex
ansys.fluent.core.launcher.launcher.LaunchFluentError:
Fluent Launch string: start "" "D:\ANSYSDev\vNNN\fluent\ntbin\win64\fluent.exe" 3ddp   -sifile="C:\Users\mkundu\AppData\Local\Temp\serverinfo-1aqp0o22.txt" -nm -hidden

New behaviour (fails immediately after Fluent is launched and shows the grpc error message):

>>> solver = pyfluent.launch_fluent()
pyfluent.launcher ERROR: Exception caught - RuntimeError: failed to connect to all addresses; last error: UNAVAILABLE: ipv6:%5B::1%5D:12345: Connection refused
Traceback (most recent call last):
  File "D:\ANSYSDev\PyFluentDev\pyfluent\src\ansys\fluent\core\launcher\launcher.py", line 745, in launch_fluent
    session = new_session.create_from_server_info_file(
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\ANSYSDev\PyFluentDev\pyfluent\src\ansys\fluent\core\session.py", line 226, in create_from_server_info_file
    fluent_connection=FluentConnection(
                      ^^^^^^^^^^^^^^^^^
  File "D:\ANSYSDev\PyFluentDev\pyfluent\src\ansys\fluent\core\fluent_connection.py", line 272, in __init__
    self.health_check_service.check_health()
  File "D:\ANSYSDev\PyFluentDev\pyfluent\src\ansys\fluent\core\services\error_handler.py", line 15, in func
    raise RuntimeError(ex.details()) from None
RuntimeError: failed to connect to all addresses; last error: UNAVAILABLE: ipv6:%5B::1%5D:12345: Connection refused

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\ANSYSDev\PyFluentDev\pyfluent\src\ansys\fluent\core\launcher\launcher.py", line 779, in launch_fluent
    raise LaunchFluentError(launch_cmd) from ex
ansys.fluent.core.launcher.launcher.LaunchFluentError:
Fluent Launch string: start "" "D:\ANSYSDev\vNNN\fluent\ntbin\win64\fluent.exe" 3ddp   -sifile="C:\Users\mkundu\AppData\Local\Temp\serverinfo-z5hlusk9.txt" -nm -hidden

[raph-luc]

This is a great idea, but the test_recover_grpc_error_from_launch_error is going to leave unreachable zombies behind (watchdog also not going to work due to incorrect port number), and I have an idea of how to make this test work with containers as well, and clean up after itself so it doesn't leave zombies, going to see if I can make some suggestions

Edit: if you prefer, can merge this without the test for now, and then we can add more robust tests in a separate PR

[mkundu1]

This is a great idea, but the test_recover_grpc_error_from_launch_error is going to leave unreachable zombies behind (watchdog also not going to work due to incorrect port number), and I have an idea of how to make this test work with containers as well, and clean up after itself so it doesn't leave zombies, going to see if I can make some suggestions

Edit: if you prefer, can merge this without the test for now, and then we can add more robust tests in a separate PR

Thanks @raph-luc, this is a good point. Feel free to merge your suggestions directly to this branch if you prefer. We'll complete the PR sometime next week.

[mkundu1]

Thanks @raph-luc, I've kept both tests. Both are useful examples of how to recover the grpc error in those scenarios.