core: Dependencies and timeout issues after 0.114 upgrade

The problem

With latest release 0.114 dependencies and timeout issues occured. Specifically:

  • recorder
  • logbook
  • history_stats

These issues did not occur on hass 0.113.

Environment

  • Home Assistant Core release with the issue: 0.114.1
  • Last working Home Assistant Core release (if known): 0.113.x
  • Operating environment (OS/Container/Supervised/Core): HomeAsistant supervised on Ubuntu 20
  • Integration causing this issue: recorder
  • Link to integration documentation on our website:

Problem-relevant configuration.yaml

Just default config will triger the issue

default_config:

Traceback/Error logs

2020-08-12 20:42:26 WARNING (MainThread) [homeassistant.setup] Setup of recorder is taking over 10 seconds.
2020-08-12 20:43:16 WARNING (MainThread) [homeassistant.bootstrap] Waiting on integrations to complete setup: recorder
2020-08-12 20:44:16 WARNING (MainThread) [homeassistant.bootstrap] Waiting on integrations to complete setup: recorder
2020-08-12 20:45:16 WARNING (MainThread) [homeassistant.bootstrap] Waiting on integrations to complete setup: recorder
2020-08-12 20:46:16 WARNING (MainThread) [homeassistant.bootstrap] Waiting on integrations to complete setup: recorder
2020-08-12 20:47:16 WARNING (MainThread) [homeassistant.bootstrap] Waiting on integrations to complete setup: recorder
2020-08-12 20:47:16 ERROR (MainThread) [homeassistant.setup] Setup of recorder is taking longer than 300 seconds. Startup will proceed without waiting any longer

https://paste.ubuntu.com/p/nnWkD87McY/ leave a message if link is expired

Additional information

Probably something to do with #37949 My database size is 5,5GB

Shouldn’t this database check run async and give the user the option what to do. Newer sqlite versions can recover databases if a users wants to try that road.

removing the datbase is a solution but is it the best solution? Will the issue return when databases get larger again. #38804 #38810 #38897

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 18 (9 by maintainers)

Most upvoted comments

That is shockingly slow for a quick_check. quick_check is intended to be quick per its namesake. I think we will have to freeze the timeout for this use case.