Fix flaky remote test on slow runners (quit mainloop when client finishes)

[dccote]

Problem

ubuntu-latest / py3.11 fails deterministically on testRemote.TestRemoteServer.test_proxy_validates_against_signatures (it reproduced on a clean re-run), while all 10 other OS×Python combinations pass:

xmlrpc.client.Fault: <Fault 1: "<class 'TimeoutError'>:">
AssertionError: None != 5

Root cause

The test harness _run_with_client ran the Tk mainloop for a fixed 1.5 s window and then quit unconditionally:

self.app.after(int(timeout / 4), thread.start)
self.app.after(timeout, self.app.quit)   # hard cut at 1.5s

Every remote call is marshaled onto the Tk main thread (schedule_on_main_thread → run_main_queue), and the server blocks on future.result(timeout=30) until the main thread services it. Most tests do one round-trip. This is the only test whose client uses RemoteAppProxy, which does three (connect → remote_signatures → add) because it validates the call against the server's advertised signatures first. On the slow ubuntu-3.11 runner (full suite ~103 s there) the mainloop quit before add's task was serviced, so the future timed out and the client received None.

Fix

Quit as soon as the client thread finishes (polled on the main thread via after) instead of after a fixed delay. The queue keeps draining until the client is done, so a slow runner gets as long as it needs. The fixed time becomes a 5 s safety net so a genuinely hung call cannot wedge the suite.

Applied to both identical copies of the harness (TestRemoteServer and TestRemoteCommands).

Result

• Fixes the ubuntu-3.11 failure at the source (no more fixed-window race).
• Test-only change — no library/behavior change, so no CHANGELOG entry.
• Bonus: the suite is faster (7.7 s locally vs the old ~20 s+), since quick clients no longer wait out the full window.

🤖 Generated with Claude Code