New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sonos setup fails with unhandled exceptions on discovery messages #90648
Conversation
Hey there @cgtobi, @jjlawren, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
1. Speaker activity messages were being sent for speakers whose pings fail, resulting in the speaker remaining available in HASS. Now the activity message is only sent after a successful ping. 2. Remove RequestException from except handler as its a derived class of OSError() 3. If the second host in a list of two hosts was unavailable, then a blocking call would occur in the event loop. Now, fully process the lists of hosts in the first loop; and only process hosts there are not in error in the second loop.
@jjlawren changes are complete, please review when you have a couple A question you may have is why I moved the async_dispatcher_send after the ping. What I found is when I unplugged a speaker that message would get sent and that was keeping the speaker alive beyond the ~270 second timeout so it would not get marked unavailable. Moving it after a successful ping eliminates that problem at which point that message makes the speaker become available. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for testing thoroughly. Getting the failure scenarios for Sonos devices is tricky as network layouts and behaviors vary wildly. This manual polling code should only be necessary when the various discovery methods are not operational. I have tested many similar scenarios by forcibly breaking discovery on my network but it's not a setup I enjoy re-testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can see how this helps during startup. Should be a good improvement. Thanks again for testing and the PR 👍
Thank you for the review. While I don't expect any issues as we now have much better unit tests. If for some reason an issue is reported on this piece of code, tag me and I'll get right on it. |
Second opinion request is for #90648 (comment) |
@@ -84,7 +99,9 @@ async def test_async_poll_manual_hosts_warnings( | |||
manager.hosts.add("10.10.10.10") | |||
with caplog.at_level(logging.DEBUG), patch.object( | |||
manager, "_async_handle_discovery_message" | |||
), patch("homeassistant.components.sonos.async_call_later"), patch( | |||
), patch( | |||
"homeassistant.components.sonos.async_call_later" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably shouldn’t be patching async_call_later here but that’s an existing issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, that's from a prior test. I'll get that fixed in a new pull request.
@jjlawren please review when you have 5. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This codepath should only be needed when network discovery is failing and manually configured hosts are required. Tests are a bit more complex now, but the previous limitation of a single mocked device is good to relax. Thanks for the thorough testing here 👍
Pushed to my production to verify that it didn't cause any side effects. All good 👍 |
Merging in dev to get a clean CI run before merging |
Thanks @PeteRager |
Proposed change
During setup of manually configured Sonos devices, if the devices are offline setup of the integration may fail. There were several issues in the code that needed to be resolved.
Type of change
Additional information
Checklist
black --fast homeassistant tests
)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest
.requirements_all.txt
.Updated by running
python3 -m script.gen_requirements_all
..coveragerc
.To help with the load of incoming pull requests: