* Start the Supervisor auto update on every version reload
A pending Supervisor update blocks Core, OS and app updates through the SUPERVISOR_UPDATED job condition. Only the startup and the daily scheduled reload started the auto update. Every other reload, such as the one Core requests when the user opens Settings, made the new version known without installing it. The user then saw "supervisor needs to be updated first" until the daily task ran.
The updater now starts the auto update task after every reload while the system is running. The scheduled task calls the updater reload directly. The Supervisor update job rejects a concurrent update request, so a user requested update during the auto update fails cleanly instead of creating an update failed issue.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SAWqYzDiFEvYjZwfBWoxkC
* Report success for an update request during a running Supervisor update
The auto update can already run when Core or a user requests the update. The requested outcome is underway, so the API reports success and the caller sees the result through the Supervisor restart.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SAWqYzDiFEvYjZwfBWoxkC
* Trim comments around the Supervisor auto update
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SAWqYzDiFEvYjZwfBWoxkC
* Drop comment on the updater auto update trigger
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SAWqYzDiFEvYjZwfBWoxkC
* Raise specific errors when restoring a backup requires a Supervisor update
Move the supervisor version check in do_restore_full/do_restore_partial into
a shared _check_supervisor_version helper. If the backup requires a newer
Supervisor version:
- Raise the new translatable BackupSupervisorVersionError (400) with the
existing message when auto update is disabled.
- Otherwise kick off the Supervisor auto update in the background via
sys_create_task(auto_update_supervisor()) and raise the new translatable
BackupSupervisorUpdateInProgressError (503), telling the caller to retry
once the update completes.
* Recheck for Supervisor update before failing a version-mismatch restore
When a restore requires a newer Supervisor version and auto update is
enabled, refresh version info first in case a newer Supervisor was just
released. If an update is already known to be needed, make sure it gets
kicked off directly instead of waiting on a reload. Only fall back to
the translatable version-mismatch error if no update is available after
the recheck.
Also move auto_update_supervisor from Tasks to the Supervisor class so
it can be reused outside of the task scheduler.
* Track auto update and version fetch tasks to close restore-check races
Supervisor.auto_update_supervisor() now stores and returns its update
task (created with eager_start so a synchronous failure is reflected
immediately) instead of firing-and-forgetting it. This lets callers
check the task's actual done state rather than guessing based on
need_update, which could be wrong if the update job rejected the call
for an unrelated reason.
HomeAssistantCore's install retry loop now also catches
SupervisorJobError when triggering the Supervisor update it depends on,
so it keeps retrying while an update is already in progress instead of
giving up.
Add Updater.start_fetch_data(), which starts (or reuses) a version
fetch and returns its task. fetch_data() sets its throttle timestamp
before running, even on failure, so a caller relying on fetch_data()
directly can't tell "someone else just refreshed" from "someone else's
fetch just failed" - it would silently skip either way. Callers that
need to know the true outcome should await the shared task instead.
reload() and BackupManager._check_supervisor_version() are updated to
use it: the latter awaits the fetch task directly (skipping it entirely
if there's no connectivity to fetch with) before checking
auto_update_supervisor()'s task, closing a race where a stale/failed
throttle window could cause a 400 (version mismatch) response instead
of a 503 (update in progress).
* Use Job decorator's detach option for update and version fetch tasks
#7211 added a `detach` option to the Job decorator, making the manual
task-tracking previously added here redundant. Replace it with the
decorator-native option:
- `Supervisor.update()` is now `detach=True` with
`concurrency=JobConcurrency.REJECT`. Calling it returns the task
performing the update - which may already be in progress from any
previous caller, manual or automatic - instead of raising
`SupervisorJobError` or blocking the caller until it (and the
Supervisor restart it triggers) completes. Errors are raised on the
returned task, not to the immediate caller.
- `Supervisor.auto_update_supervisor()` is now a thin, non-detached
method that simply returns `update()`'s own task directly instead of
tracking a separate task itself. This ensures a concurrent manual
update and an auto update share the exact same underlying task
regardless of which caller started it. It never awaits the task to
completion, since update() restarts Supervisor and awaiting that here
could drop the caller's connection before a response is sent.
- `Updater.fetch_data()` is now `detach=True` with
`concurrency=JobConcurrency.REJECT`, replacing the bespoke
`start_fetch_data()`/`_fetch_task` tracking. `reload()` and
`BackupManager._check_supervisor_version()` await the returned task
directly to get the real outcome of a fetch instead of relying on the
throttle window.
- The Supervisor update API endpoint and the Home Assistant Core
install retry loop now use `if task := await ...: await task` instead
of catching `SupervisorJobError`, since a concurrent call no longer
raises that error - it returns the shared in-progress task instead.
Updated tests across supervisor.py, updater.py, the API and Home
Assistant Core install retry loop to match the new return values and
removed now-obsolete `SupervisorJobError`-based concurrency tests.
* Fix too-many-nested-blocks pylint warning in HomeAssistantCore.install()
Flatten the nested need_update/auto_update if/else into an if/elif so
the Supervisor update retry try/except isn't nested one level deeper,
which pylint 4.0.8 (unlike the previously installed version in this
container) now flags as too-many-nested-blocks (6/5). Cache
need_update in a local variable since it's now referenced twice in the
same iteration and must be consistent between both checks.
* Update supervisor/api/supervisor.py
---------
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Co-authored-by: Mike Degatano <michael.degatano@gmail.com>
Co-authored-by: Stefan Agner <stefan@agner.ch>
* Rename addon→app in docstrings and comments
Updates all docstrings and inline comments across supervisor/ and
tests/ to use the new app/apps terminology. No runtime behaviour
is changed by this commit.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Rename addon→app in code (variables, args, class names, functions)
Renames all internal Python identifiers from addon/addons to app/apps:
- Variable and argument names
- Function and method names
- Class names (Addon→App, AddonManager→AppManager, DockerAddon→DockerApp,
all exception, check, and fixup classes, etc.)
- String literals used as Python identifiers (pytest fixtures,
parametrize param names, patch.object attribute strings,
URL route match_info keys)
External API contracts are preserved: JSON keys, error codes,
discovery protocol fields, TypedDict/attr.s field names.
Import module paths (supervisor/addons/) are also unchanged.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fix partial backup/restore API to remap addons key to apps
The external API accepts `addons` as the request body key (since
ATTR_APPS = "addons"), but do_backup_partial and do_restore_partial
now take an `apps` parameter after the rename. The **body expansion
in both endpoints would pass `addons=...` causing a TypeError.
Remap the key before expansion in both backup_partial and
restore_partial:
if ATTR_APPS in body:
body["apps"] = body.pop(ATTR_APPS)
Also adds test_restore_partial_with_addons_key to verify the restore
path correctly receives apps= when addons is passed in the request
body. This path had no existing test coverage.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fix merge error
* Adjust AppLoggerAdapter to use app_name
Co-authored-by: Stefan Agner <stefan@agner.ch>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Stefan Agner <stefan@agner.ch>
* Store and persist OS upgrade map to fix update path evaluation
The existing logic calculated OS upgrade paths inline during fetch_data,
which will not get reevaluted when the current OS is unsupported
(JobCondition.OS_SUPPORTED). E.g. after updating from 11.4 to 11.5, the
system wouldn't offer the next available update (15.2) because the
upgrade path calculation relied on fresh data from the blocked fetch
operation.
Changes:
- Add ATTR_HASSOS_UPGRADE constant and schema validation
- Store hassos-upgrade map from version JSON in updater data
- Refactor version_hassos property to use stored upgrade map instead of
inline calculation during fetch_data
- Maintain upgrade path logic: upgrade within major version first, then
jump to next major version when at the latest in current major
- Add type safety checks for version.major access
This ensures upgrade paths work correctly even when update data refresh
is blocked due to unsupported OS versions, fixing the scenario where
HAOS 11.5 wouldn't show 15.2 as the next available update.
* Update supervisor/updater.py
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Address mypy issue
* Fix pytest
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Add dedicated update information reload
Currently we have the /refresh_updates endpoint which updates the main
component versions (Core, OS, Supervisor, Plug-ins) and the add-on
store at the same time. This combined update causes more update
information reloads than necessary.
To allow fine grained update refresh control introduce a new endpoint
/reload_updates which asks Supervisor to only update main component
versions (learned through the version json files).
The /store/reload endpoint already allows to update the add-on store
separately.
* Add pytest
* Update supervisor/api/__init__.py
* Use version which is treated CalVer by AwesomeVersion
The current dev version `99.9.9dev` is treated as unkown version type
by AwesomeVersion. This prevents the version from comparing with
actual Supervisor versions, e.g. from an exsiting backup file.
Make the development version a valid CalVer version so development
versions can handle non-development backups.
* Bump to year 9999
* Install dbus applications for CI tests
* Update const.py
* fix tests
* Fix test references to DEV version
* sudo apt-get
* Update builder.yml
---------
Co-authored-by: Mike Degatano <michael.degatano@gmail.com>
Pascal VizeliandMike Degatano