[NicolasBonduel]

Fixes #238.

Problem

The MQTT TLS proxy does the TLS handshake inside its accept loop, on a blocking socket with no timeout. If one client stalls before finishing the handshake, accept() stays blocked for everyone else, including vacuums, Home Assistant and apps, until the OS gives up on that socket. On a lossy Wi-Fi link that took about 15 minutes per stalled attempt. The robot's retries kept stalling the same way, and the listener stayed blocked for hours until the add-on was restarted. Connections that were already established kept working; only new ones were blocked.

Fix

The accept loop now only calls accept() and hands the raw socket to a per-client thread. That thread sets a 10 s timeout, does the handshake, clears the timeout and then runs the existing _handle_client. A stalled handshake now ties up only its own thread and fails with the existing TLS handshake failed ... warning after 10 s. Plain MQTT mode (tls_enabled=False) goes through the same path.

Clearing the timeout before the relay keeps established connections in blocking mode, as before. The wait for the MQTT CONNECT packet is still unbounded, but it now happens on the client's own thread, so it can't block other clients.

Tests

Two new end-to-end tests in tests/test_mqtt_tls_proxy.py start the proxy on a free local port with a self-signed certificate:

• a TLS handshake succeeds while another client holds an idle TCP connection open
• the idle connection is closed by the server once the handshake timeout passes

Both tests fail on main and pass with the fix. Full suite: 460 passed. These tests are the first to build a real TLS context, so they show the existing ssl.TLSVersion.TLSv1 is deprecated warning from the intentional TLS 1.0 support for older firmware.

The reproduction script in #238 shows the same behaviour against a running stack.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The regression test can pass despite a blocked accept loop because the idle client’s 0.5-second server timeout expires within the healthy client’s 2-second deadline, masking serialized handshakes.

1 open issue

• Use a longer handshake timeout to detect serialized handshakes · New

What changed in this PR

This PR addresses #238 by preventing a stalled TLS handshake from blocking new connections to the MQTT proxy.

Changes:

• Moves connection setup into per-client threads.
• Adds a 10-second handshake timeout and restores blocking mode before client handling.
• Adds real-TLS tests for concurrent connection acceptance and stalled-handshake cleanup.

File	Description
tests/​test_mqtt_tls_proxy.py	Adds a TLS fixture and two stalled-handshake regression tests.
src/​roborock_local_server/​bundled_backend/​mqtt_tls_proxy_server/​server.py	Moves handshakes off the accept loop and bounds their duration.

_{Review effort: Balanced}