Improve Supervisor update entity progress and data refresh#168712
Merged
Conversation
After a Supervisor update completes, the Supervisor restarts. However, the hassio coordinator still serves stale version data until its next 5-minute scheduled refresh. During that window the Supervisor update entity reports the just-installed version as an available update, and pressing Update again triggers an install against a restarting or already updated Supervisor which fails with a confusing error. Listen for the Supervisor STARTUP_COMPLETE event on the coordinator and trigger a debounced refresh, so all entities reflect the real state within seconds of Supervisor coming back online. Also add progress tracking for Supervisor updates, which previously showed no download progress or installing state (unlike Core and add-on updates). Subscribe to the supervisor_update job to surface download progress. The Supervisor update HTTP call returns after the container download completes but while Supervisor is still restarting; the base UpdateEntity resets _attr_in_progress at that point. A separate _update_ongoing flag - cleared once the coordinator observes a changed installed version - keeps the installing state visible across the restart. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Covers the three new behaviors: - Progress events from the supervisor_update job update in_progress and update_percentage on the Supervisor update entity. - After install returns, in_progress stays True until Supervisor fires STARTUP_COMPLETE and the coordinator picks up a new installed version. - Completion is detected by a change from the pre-install installed version, not by matching latest_version, so a concurrent upstream bump does not leave the entity stuck in progress.
home-assistant
Bot
added
cla-signed
core
has-tests
by-code-owner
Quality Scale: internal
labels
Contributor
|
Hey there @home-assistant/supervisor, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
Contributor
There was a problem hiding this comment.
Pull request overview
This PR improves the hassio integration’s Supervisor update UX by (1) surfacing download progress via Supervisor job events and (2) triggering a debounced coordinator refresh after the Supervisor restarts, avoiding stale version/update state for several minutes after an update.
Changes:
- Add progress reporting to the Supervisor update entity by subscribing to the
supervisor_updatejob and exposingUpdateEntityFeature.PROGRESS. - Keep the Supervisor update entity in an installing state across the Supervisor restart using an
_update_ongoingflag that clears once the installed version changes. - Refresh the Hass.io main coordinator (debounced) on Supervisor
STARTUP_COMPLETEafter a Supervisor update, and add tests covering progress + restart behavior.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
homeassistant/components/hassio/update.py |
Adds Supervisor update progress support and preserves “in progress” across Supervisor restart until the coordinator observes a version change. |
homeassistant/components/hassio/coordinator.py |
Listens for Supervisor STARTUP_COMPLETE (Supervisor update) events and requests a debounced coordinator refresh to avoid stale version/update info. |
tests/components/hassio/test_update.py |
Adds tests for Supervisor update progress reporting and ensuring in_progress remains true until post-restart refresh/version change. |
Supervisor updates can be triggered outside the UI (CLI, Supervisor self-update). Those paths never call async_install on the entity, so the _update_ongoing flag added for the user-initiated flow was never set. The entity would show download progress from the supervisor_update job subscription, then flip to "update available" for the few seconds between the job completing and the coordinator refresh observing the new installed version. Capture the baseline version and set _update_ongoing the first time _update_job_changed sees a running job, so the installing state is held across the restart phase regardless of who initiated the update. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Breaking change
Proposed change
After a Supervisor update completes, the Supervisor restarts. However, the hassio coordinator still serves stale version data until its next 5-minute scheduled refresh. During that window the Supervisor update entity reports the just-installed version as an available update, and pressing Update again triggers an install against a restarting Supervisor which fails with a confusing error.
Listen for the Supervisor
STARTUP_COMPLETEevent on the coordinator and trigger a debounced refresh, so all entities reflect the real state within seconds of Supervisor coming back online.Also add progress tracking for Supervisor updates, which previously showed no download progress or installing state (unlike Core and add-on updates). Subscribe to the
supervisor_updatejob to surface download progress. The Supervisor update HTTP call returns after the container download completes but while Supervisor is still restarting; the base UpdateEntity resets_attr_in_progressat that point. A separate_update_ongoing flag- cleared once the coordinator observes a changed installed version - keeps the installing state visible across the restart.Type of change
Additional information
Checklist
ruff format 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.To help with the load of incoming pull requests: