CI intermittently fails on Roborock MQTT

[CoMPaTech]

The problem

This happened a lot the past few weeks when running CI. Already asked one of the code owners on discord, but let's formalise it here.

Reference: https://github.com/home-assistant/core/actions/runs/16727295211/job/47346877184

Original text: I got side-tracked in PR updates with CI failing, unfortunately roborock being one of them - most likely due to paho.mqtt fixtures. Is this something already looked in to? I was tempted to do a PR, but the mqtt thing seems a bit deeper. Fwiw, easy fix is the below one for another occuring issue (but that's not whats threading the waters).
And no tests pass, but some exceptions hinder CI apparently (we had the same in Plugwise).

async def test_options_flow_drawables(
    hass: HomeAssistant, mock_roborock_entry: MockConfigEntry
    hass: HomeAssistant, bypass_api_fixture, mock_roborock_entry: MockConfigEntry
) -> None:

I can PR just that one if you like, but I would hate trying to fix the mqtt parts if you are already aware

What version of Home Assistant Core has the issue?

n/a

What was the last working version of Home Assistant Core?

n/a

What type of installation are you running?

Home Assistant OS

Integration causing the issue

roborock

Link to integration documentation on our website

https://www.home-assistant.io/integrations/roborock/

Diagnostics information

See example output of the action https://github.com/home-assistant/core/actions/runs/16727295211/job/47346877184

ERROR tests/components/roborock/test_config_flow.py::test_reauth_flow - AssertionError: assert (False or False or '_run_safe_shutdown_loop' in 'paho-mqtt-client-')

• where False = isinstance(<Thread(paho-mqtt-client-, started daemon 140680630134464)>, <class 'threading._DummyThread'>)
• where <class 'threading._DummyThread'> = threading._DummyThread
• and False = <built-in method startswith of str object at 0x7ff348efa7b0>('waitpid-')
• where <built-in method startswith of str object at 0x7ff348efa7b0> = 'paho-mqtt-client-'.startswith

•  where 'paho-mqtt-client-' = <Thread(paho-mqtt-client-, started daemon 140680630134464)>.name
  

• and 'paho-mqtt-client-' = <Thread(paho-mqtt-client-, started daemon 140680630134464)>.name
  Error: Process completed with exit code 1.

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

No response

[home-assistant]

Hey there @Lash-L, @allenporter, mind taking a look at this issue as it has been labeled with an integration (roborock) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of roborock can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign roborock Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

roborock documentation
roborock source
_{^{(message by IssueLinks)}}

[allenporter]

Looks like some of the code to patch out the real mqtt is being missed somewhere, then it leaves the thread (which is unable to make a network connection) dangling.

[allenporter]

Next step is to figure out which path is causing the mqtt client to be created w/o being patched out.

[CoMPaTech]

Adding the mock I indicated at least gives it some breathing room, but indeed it was a bit more as well. I could attempt it unless either of you are already on it, saves some precious and unnecessary time waiting for CI.

[CoMPaTech]

Spending a little while with it testing through test_config_flow.py besides the suggested patch, adding a async_block_till_done to the reauth_flow (at the end of the definition) brings the test-duration down from 1.5s to nothing. So it's definitely the teardown, but not sure how the adding of the block helps with it

# test_config_flow.py changes
async def test_reauth_flow(
    hass: HomeAssistant, bypass_api_fixture, mock_roborock_entry: MockConfigEntry
) -> None:
    """Test reauth flow."""
(...)
    assert mock_roborock_entry.unique_id == ROBOROCK_RRUID
    assert mock_roborock_entry.data["user_data"]["rriot"]["s"] == "new_password_hash"
 +   await hass.async_block_till_done()


async def test_account_already_configured(
    hass: HomeAssistant,

(...)
async def test_options_flow_drawables(
-    hass: HomeAssistant, mock_roborock_entry: MockConfigEntry
+    hass: HomeAssistant, bypass_api_fixture, mock_roborock_entry: MockConfigEntry
) -> None:

For reference, with fugly thing in place:

0.11s call     tests/components/roborock/test_config_flow.py::test_reauth_flow
0.08s setup    tests/components/roborock/test_config_flow.py::test_reauth_flow
0.01s teardown tests/components/roborock/test_config_flow.py::test_reauth_flow

from

1.49s teardown tests/components/roborock/test_config_flow.py::test_reauth_flow
0.11s setup    tests/components/roborock/test_config_flow.py::test_reauth_flow
0.08s call     tests/components/roborock/test_config_flow.py::test_reauth_flow

The test in options_flow_drawables also fixes the DNS issues (as expected).

[CoMPaTech]

fwiw ... Error: 3.01s call tests/components/roborock/test_select.py::test_update_success[select.roborock_s7_maxv_selected_map-Downstairs] is also taking it's sweet time, didn't profile it yet to see what/where other than

3.00s call     tests/components/roborock/test_select.py::test_update_success[select.roborock_s7_maxv_selected_map-Downstairs]
0.17s setup    tests/components/roborock/test_select.py::test_update_success[select.roborock_s7_maxv_mop_mode-deep]
0.09s setup    tests/components/roborock/test_select.py::test_update_success[select.roborock_s7_maxv_selected_map-Downstairs]
0.09s setup    tests/components/roborock/test_select.py::test_update_success[select.roborock_s7_maxv_mop_intensity-mild]
0.01s teardown tests/components/roborock/test_select.py::test_update_success[select.roborock_s7_maxv_selected_map-Downstairs]
0.01s teardown tests/components/roborock/test_select.py::test_update_success[select.roborock_s7_maxv_mop_mode-deep]

[allenporter]

(1) See #150135 which may have addressed failures and you can see root cause
(2) For speed: MQTT creates background threads and also can take a moment to shut down, so its important not to let the paho mqtt client start at all.