Start frontend in time for database upgrades#48704
Start frontend in time for database upgrades#48704bdraco wants to merge 36 commits intohome-assistant:devfrom
Conversation
|
Saw users do this as part of the current beta. I think its too late to include this since there isn't enough test runway to feel comfortable about it, but at least it will hopefully mitigate this from happening in the future |
|
I've been testing with this all day ~100 restarts and no issues. We don't have tests for loading in specific order so I didn't change any tests and everything still passes. |
|
We should probably promote all deps for stage 0 as well like we do for stage 1 |
|
I think I might throw this away and start over. Maybe a with setup.XXXX for the defer |
bdraco
force-pushed
the
start_frontend_in_time_for_database_upgrade
branch
3 times, most recently
from
d1fbdbc to
abedcf6
Compare
|
TODO tomorrow:
|
If a database check or upgrade is in progress the frontend would not start soon enough which would leave users wondering why their instance was not working and restart it again which lead to their database being corrupted.
bdraco
force-pushed
the
start_frontend_in_time_for_database_upgrade
branch
from
65f26bd to
73674c2
Compare
|
Need to validate this behaves reasonably when the MySQL database can't connect. Wrong password should be a good test |
This reverts commit 6b145f3.
|
All looks good in testing. I've been slowly increasing the recorder coverage each time and this should get it to ~93% |
|
After thinking about this for a while, I think it's better to just start up and watch the size of the event queue to ensure it doesn't exhaust ram. Then we can do database migrations live, without users waiting hours with their instance to be available again. I think we only need to wait for the database connected event, then let recorder keep going in the background. We can start a task to watch the size of the queue, and if it gets too big, then we start the starting discarding events. Considering they wouldn't be recorded anyway because of the migration blocking start up that Seems like a good compromise |
|
I should build it on top of this though to avoid the review being too big |
| # If there is a database upgrade in progress the recorder | ||
| # queue can exaust the available memory if we allow stage 2 | ||
| # to start. We wait until the upgrade is completed before | ||
| # starting. | ||
| await async_wait_for_recorder_full_startup(hass) | ||
|
|
| RECORDER_BASE_SETUP_TIMEOUT = 60 | ||
|
|
||
|
|
||
| async def async_wait_for_recorder_full_startup(hass: HomeAssistant) -> None: |
This PR is superseded by: #49036 |
3 participants
This PR is superseded by: #49036
After thinking about this for it a bit, it makes sense to do this in one PR since it can now be completely self contained in the recorder integration
Proposed change
If a database check or upgrade is in progress the frontend
would not start soon enough which would leave users wondering
why their instance was not working and restart it again which
lead to their database being corrupted.
I did a bit refactoring to increase test coverage as well as I
wanted to ensure there wasn't a path were the recorder thread
would fail to set the result and block forever.
Type of change
Example entry for
configuration.yaml:# Example configuration.yamlAdditional information
Checklist
black --fast 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..coveragerc.The integration reached or maintains the following Integration Quality Scale:
To help with the load of incoming pull requests: