mirror of
https://github.com/home-assistant/supervisor.git
synced 2026-10-01 07:27:03 +01:00
Stefan AgnerandClaude Fable 5.1
b44b4acbc2
* Add detach option to the Job decorator A job decorated with detach=True awaits its conditions, concurrency control and throttling as before, but then runs the method in a separate task and returns that task to the caller. A refused job returns None (or raises on_condition, as today). With REJECT concurrency a call while the job is running returns the running task instead of raising. The task releases the concurrency lock and cleans up the job record when it completes. Group concurrency is not supported in this mode. This gives callers a definitive answer on whether a long running job was started, without having to await its completion. The Supervisor auto update needs this: a backup restore that requires a newer Supervisor has to know whether the update actually started before it tells the caller to wait for it, and the update itself stops the Supervisor, so it cannot be awaited from within an API request. Until now the only way to get that answer was to eagerly start the wrapped call as a task and inspect its done state, which silently depends on none of the job conditions suspending before the refusal. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Run detached jobs as root jobs and record throttled calls up front A detached job runs in a task created through sys_create_task, which clears the current job in the new context. A job created with the caller's job as parent therefore could not start there and raised JobStartException, which broke the motivating case of starting the Supervisor auto update from within the backup restore job. Create detached jobs as root jobs instead, as schedule_job already does. A detached job may outlive its caller, so it should not be a child of it anyway. The throttle bookkeeping happened inside the task, after the wrapper had returned. Two callers that were both runnable could pass the throttle check before either task ran and both start. Record the accepted call synchronously right after the throttle check in both modes; in the non-detached mode nothing suspends between the old and new place, so that behavior is unchanged. Add tests for a detached call from within a job and for concurrent calls to a throttled detached job. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Start detached job tasks eagerly so cancellation cannot skip cleanup A task cancelled before its first execution step never enters its coroutine, so the finally block in _run_detached would not run. The concurrency lock would stay held and the job would remain registered. Start the detached task eagerly so the runner is inside its try block before the task is handed to the caller. Add a test that cancels the returned task right away and checks the job is removed and a REJECT job can be started again. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Drop the reference to a finished detached job task The decorator lives for the process lifetime, so keeping the last detached task after it finished retained its result or exception traceback, along with the frames and arguments those reference, until the next call replaced it. Clear the reference from a done callback, guarded by identity so an older task cannot clear a newer one. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Home Assistant Supervisor
First private cloud solution for home automation
Home Assistant (former Hass.io) is a container-based system for managing your Home Assistant Core installation and related applications. The system is controlled via Home Assistant which communicates with the Supervisor. The Supervisor provides an API to manage the installation. This includes changing network settings or installing and updating software.
Installation
Installation instructions can be found at https://home-assistant.io/getting-started.
Development
For small changes and bugfixes you can just follow this, but for significant changes open a RFC first. Development instructions can be found here.
Release
Releases are done in 3 stages (channels) with this structure:
- Pull requests are merged to the
mainbranch. - A new build is pushed to the
devstage. - Releases are published.
- A new build is pushed to the
betastage. - The
stable.jsonfile is updated. - The build that was pushed to
betawill now be pushed tostable.
