-
Notifications
You must be signed in to change notification settings - Fork 653
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix addon in wrong state after restore #5111
Conversation
b5a399a
to
9ee7593
Compare
WalkthroughWalkthroughThe updates involve ensuring the add-on is loaded before running it in the Changes
Sequence Diagram(s) (Beta)sequenceDiagram
participant User
participant CoreSys
participant Addon
participant Docker
User->>CoreSys: Initiate shutdown
CoreSys->>Docker: Stop Docker monitoring (removed)
CoreSys->>User: Shutdown complete
User->>CoreSys: Initiate restore
CoreSys->>Addon: Restore data
Addon->>Addon: Ensure add-on is loaded
Addon->>CoreSys: Add-on loaded
CoreSys->>User: Restore complete
User->>CoreSys: Run add-on (STARTED state)
CoreSys->>Addon: Check if loaded (moved to finally block)
Addon->>User: Add-on running
Recent review detailsConfiguration used: CodeRabbit UI Files selected for processing (3)
Additional context usedPath-based instructions (1)
Additional comments not posted (3)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Outside diff range comments (1)
supervisor/core.py (1)
[!TIP]
Codebase VerificationThe reference to
sys_docker.unload()
is part of a list of coroutines that are being stopped during the shutdown process. This indicates that Docker monitoring is still being unloaded during shutdown, which contradicts the intended change.
supervisor/core.py
: Thesys_docker.unload()
call is still present in the shutdown process.Analysis chain
Line range hint
318-318
: Change approved: Docker monitoring is no longer unloaded during shutdown.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that Docker monitoring remains active during the shutdown process and does not negatively affect other operations. # Test: Search for any other references to `sys_docker.unload` to ensure it's not called elsewhere during shutdown. rg --type python $'sys_docker.unload'Length of output: 67
Script:
#!/bin/bash # Description: Verify that Docker monitoring remains active during the shutdown process and does not negatively affect other operations. # Test: Search for any other references to `sys_docker.unload` to ensure it's not called elsewhere during shutdown. rg 'sys_docker.unload'Length of output: 95
Script:
#!/bin/bash # Description: Extract the relevant lines around the reference to `sys_docker.unload` in `supervisor/core.py` to understand its context. # Extract lines around the reference to `sys_docker.unload` rg 'sys_docker.unload' -A 5 -B 5 supervisor/core.pyLength of output: 475
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I see there is another sys_docker.unload()
in stop()
, which should take care in the actual shutdown case. Maybe shutdown()
as a function name on the (Supervisor-)Core class is a bit misleading 😅
Nice find, LGTM!
The restore progress actually timed out on the add-on startups:
While they were actually already running:
Which make sense, since the Docker event monitor wasn't running at this stage. |
These timeouts did also appear in this issue report, so this most likely fixes #4814. |
Proposed change
Full restore currently stops the docker events listener before it begins as part of
shutdown
. It is not restarted afterwards leaving the addons in completely unknown states beyond that point. This PR fixes that issue, the docker monitor is no longer stopped.It also fixes a minor possible issue where addons were not loaded prior to being restarted during a restore due to an exception. The first is the real cause of these "unknown state after restore" issues though.
Type of change
Additional information
Checklist
ruff format supervisor tests
)If API endpoints of add-on configuration are added/changed:
Summary by CodeRabbit
Bug Fixes
finally
block.Improvements
Tests