In some cases of network instability (e.g. DNS server reset or similar) if aexpect is in use this will result in possibly job crashing errors like
File "/usr/lib/python3.13/site-packages/aexpect/remote_door.py", line 308, in run_subcontrol
remote_control_path = _copy_control(session, control_path)
File "/usr/lib/python3.13/site-packages/aexpect/remote_door.py", line 283, in _copy_control
remote.copy_files_to(
~~~~~~~~~~~~~~~~~~~~^
session.host,
^^^^^^^^^^^^^
...<5 lines>...
remote_control_path,
^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/lib/python3.13/site-packages/aexpect/remote.py", line 1378, in transfer
ret = func(*args, **kwargs)
File "/usr/lib/python3.13/site-packages/aexpect/remote.py", line 1432, in copy_files_to
scp_to_remote(
~~~~~~~~~~~~~^
address,
^^^^^^^^
...<10 lines>...
interface=interface,
^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/lib/python3.13/site-packages/aexpect/remote.py", line 755, in scp_to_remote
return remote_copy(
command, password_list, log_filename, log_function, timeout
)
File "/usr/lib/python3.13/site-packages/aexpect/remote.py", line 696, in remote_copy
_remote_copy(
~~~~~~~~~~~~^
session, password_list, transfer_timeout, login_timeout, method
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/lib/python3.13/site-packages/aexpect/remote.py", line 646, in _remote_copy
raise SCPError("SCP client said 'lost connection'", text)
I think it might be a good idea if the remote copy operations support a number of (re)tries (with default tries=1). This will make using aexpect's remote layer in automation more resilient.
In some cases of network instability (e.g. DNS server reset or similar) if aexpect is in use this will result in possibly job crashing errors like
I think it might be a good idea if the remote copy operations support a number of (re)tries (with default
tries=1). This will make using aexpect's remote layer in automation more resilient.