[PierreRaybaut]

Fixes #398

Remote load_from_files and load_from_directory calls were sometimes silently ignored, or returned before the files were loaded, when sent right after DataLab started. Reproduced on Windows (Python 3.11, PyQt5): 4 to 5 failures out of 10 with the test of the issue.

Root cause

The XML-RPC server was started in _before_setup, before the main window was built. Remote commands are queued signals to the GUI thread: they ran as soon as setup code pumped the event loop (console setup, macro panel, remote_controlled wrappers...), on a partially built window. In instrumented runs, the load slot ran inside setup() for all 10 early requests:

• when it ran before the History panel existed, BaseDataPanel.load_from_files raised AttributeError: 'NoneType' object has no attribute 'maybe_start_session_for_input': the file was never loaded, and the error never reached the client;
• otherwise, a SIG_READY emitted by setup code (e.g. handle_autorefresh_action) set the shared is_ready flag and released the remote call before its command was done.

The lead mentioned in the issue (is_ready shared by all remote calls) is confirmed, but it only explains the early return, not the lost requests.

Changes

• Requests wait for the main window: the server binds its port at startup but serves requests only once the window is set up (_after_setup). A client connecting earlier is accepted and gets its first answer once DataLab is ready, instead of being served by a partially built window. A server still waiting can be shut down.
• Errors are reported to clients: every signal-based remote command runs through DLMainWindow.run_remote_command, which stores the exception raised by the command before signaling readiness (as call_method_slot already did). The client gets an xmlrpc.client.Fault instead of a silent success. The stored exception is reset at the start of each request.
• add_object no longer works around a missing History panel: this workaround existed only because of this race.
• Tests (remote_requests_unit_test.py): scenario of the issue for files and directory, checked right after the call without polling; error reporting for calc with an unknown function and set_object with an unknown object.
• Release notes 1.4.0.

Behavior changes for remote clients (DataLab RemoteProxy, Sigima SimpleRemoteProxy)

• Errors raised by remote commands now reach the client as xmlrpc.client.Fault; e.g. calc with an unknown function used to return True.
• A client connecting while DataLab starts now waits until DataLab is ready (about 10 s here).
• No protocol change: no XML-RPC method is added or removed.

Validation

• Instrumented background DataLab, requests sent right after connecting: 0 failures out of 20 (5 out of 10 before). In all 20 runs, requests were processed after _after_setup, and calls returned once the files were loaded.
• The new tests fail on develop (assert 0 == 1: load lost; DID NOT RAISE Fault) and pass on this branch.
• Full DataLab test suite: 1026 passed, 3 skipped.
• Ruff and Pylint (10.00/10) pass.

Out of scope

• is_ready remains a single flag shared by all remote calls: once DataLab is started, a SIG_READY emitted by an unrelated GUI action, or by a Web API request, during a pending remote call can still release it early. A per-request synchronization would remove this class of issues.
• The end-to-end test of RAW import parameters (param argument of load_from_files / load_from_directory) belongs to the RAW import branch, which should be rebased on this fix.
• Two pre-existing problems found while checking the Web API, not caused or fixed by this PR:
  • Web API started through XML-RPC (start_webapi_server): every request times out after 30 s #403: when the Web API is started through XML-RPC (start_webapi_server), its main-thread executor is created in the XML-RPC thread, so every Web API request times out after 30 s;
  • DataLab crashes (access violation) when a computation requested remotely fails #404: in a background (offscreen) DataLab, a computation failing during a remote calc (XML-RPC or Web API /calc) crashes DataLab (0xC0000005 in QMessageBox.critical, called by qt_handle_error_message).