Handle DCL vendor info timeouts during startup#1375
Conversation
|
I validated this patch on the affected HAOS 17.2 / amd64 installation by building a temporary local add-on from the official Result from the live add-on startup: And the listener is open afterwards: So the patch fixes the startup blocker at the vendor-info DCL step: the server now reaches the WebSocket bind even when the DCL vendor endpoint times out. One adjacent observation: on a fresh storage path, the earlier PAA DCL fetch can also hang until aiohttp's default ~5 minute timeout before falling back to Git. That is separate from this PR, but likely worth a follow-up timeout improvement for startup latency. |
|
Thanks a lot for your contribution. As the Readme states this project is no longer actively maintained in favor of the new Matter.js based Matter Server which is currently in Beta testing. There will be no new Python Matter Server release. The Matter.js based server already have proper timeouts and is not blocking his start because of such timeouts, so this issue is already handled there. That's why I close the PR, because it will be never released here anyway. |
Summary
TimeoutErrorthe same way asClientErrorso vendor catalog refresh remains best-effort.Why
In
MatterServer.start(),vendor_info.start()runs beforemount_websocket()andMultiHostTCPSite.start(). If the DCL vendor endpoint stalls until aiohttp raisesTimeoutError, that exception is currently not handled and the Matter Server never reaches the WebSocket bind step. Supervisor can still report the add-on service as started, butcore-matter-server:5580/wskeeps returning connection refused.This matches the startup failure being tracked in
home-assistant/addons#4560.Tests