Improve and extend frontend probe after update with WebSocket check#6811
Improve and extend frontend probe after update with WebSocket check#6811
Conversation
The post-update health check introduced in #6311 added HomeAssistantAPI.check_frontend_available, which fetched the frontend through the existing Supervisor-internal API connection to Core. Since #6742 that connection optionally runs over a Unix socket with no authentication, so the request no longer exercises the same transport, auth and routing path that an external HTTP client uses. Move the frontend probe out of HomeAssistantAPI into a small frontend_check module that talks to Core's TCP endpoints via the plain websession with no authentication, mirroring what an external client would see. While doing this, extend the post-update verification to also probe the WebSocket endpoint: open /api/websocket and confirm the first frame is the auth_required text message. This catches the kind of WebSocket breakage seen in #6802, where api/config still listed websocket_api as loaded and GET / still returned HTML, but the WebSocket handshake completed with an immediate close frame and the frontend was unusable. The component check now also requires "http" to be loaded, in addition to "frontend" and "websocket_api", and iterates so every missing component is logged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
With this if a old |
mdegat01
left a comment
mdegat01
left a comment
There was a problem hiding this comment.
This looks good. The only concern/question I have is will the websocket API check as implemented cause core to pop that "invalid auth" persistent notification? I'm not sure exactly what triggers that. I think its from the HTTP API rather then the WS API so we should be fine but just wanted to confirm that opening the connection and dropping without providing auth will not create an influx of those notifications.
- Wrap ws_connect in asyncio.wait_for so the handshake has an explicit
bounded timeout (the global websession's default timeout would
otherwise apply).
- Validate that the auth_required payload is a JSON object before
calling .get("type"); a list/string would otherwise raise
AttributeError at runtime.
- Add a regression test covering a non-dict JSON payload.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
I've not seen such a persistent notification in my tests. From looking into code, in Core's |
Proposed change
The post-update health check introduced in #6311 added
HomeAssistantAPI.check_frontend_available, which fetched the frontend through the existing Supervisor-internal API connection to Core. Since #6742 that connection optionally runs over a Unix socket with no authentication, so the request no longer exercises the same transport, auth and routing path that an external HTTP client uses.Move the frontend probe out of
HomeAssistantAPIinto a smallfrontend_checkmodule that talks to Core's TCP endpoints via the plain websession with no authentication, mirroring what an external client would see.While doing this, extend the post-update verification to also probe the WebSocket endpoint: open
/api/websocketand confirm the first frame is theauth_requiredtext message. This catches the kind of WebSocket breakage seen in #6802, whereapi/configstill listedwebsocket_apias loaded andGET /still returned HTML, but the WebSocket handshake completed with an immediate close frame and the frontend was unusable.The component check now also requires
httpto be loaded, in addition tofrontendandwebsocket_api, and iterates so every missing component is logged.Type of change
Additional information
websocket_apiintegration isn't loading #6802Checklist
ruff format supervisor tests)If API endpoints or add-on configuration are added/changed: