Will it (it being the SQLite DB rewrite) really be merged in 2024.7.2? The github issue still refers it to be a fix for 2024.8. Smart fix for the custom integrations 
Thanx for pointing out the temporary solution.
I added the lines to my configuration.yaml
Now I have seen that Frenck is working on a 2027.2 update.
I wonder if that solves the problem.
Do I have to delete the lines in my configuration.yaml after updating to 2027.2?
Yes, see:
3 Likes
Wonderful! 
This is very good! Thanks for the link and confirmation.
Yes you do.
1 Like
I’ve read the release note. Is this going to result in a full states table rebuild for those of us on mariadb as well? It’s difficult to find any information because only sqlite has been mentioned in all the talk about this bug (and mariadb as far as I can tell from my own instance doesn’t seem to have any problems), but presumably this patch will change the database version number, so will affect those of us not using sqlite as well?
Thats good news, thanks!
I’ve two questions: is it possible to reactivate icloud3 again without locking up the database because just the requests are blocked?
And: if I would migrate from SQLite to MariaDB or Influx, would that help as well?
Thanks in advance.
The problem was unique to SQLite and did not affect MySQL/maria/postgresql so there is no table rebuild for those engines.
The SQLite states table rebuild does not increment the schema version since it’s not a change in schema, its only a table rebuild to remove the old legacy schema that some systems have since SQLite currently has no way to drop a foreign key without a table rebuild. If your system was created with newer schema, this issue would never happen. It only affected older systems.
The MySQL/maria/postgresql engines have a different issue where the recorder runs out of IDs, but that only happens when you record massive amount of data over a long time. That is fixed in 2024.8.x, and you will see a migration to schema 44 there for those engines but it’s very unlikely that you have this problem unless you record 100000+ states per day.
6 Likes
Thanks for confirming that, and providing a bit more insight into things. You’re a star.
Just installed 2024.7.2 and removed the workaround. But issue remains: recorder does not work (energy dashboard and history graphs stop showing data).
At reboot:
Logger: homeassistant.setup
Source: setup.py:406
First occurred: 19:55:29 (1 occurrences)
Last logged: 19:55:29
Setup of ‘recorder’ is taking longer than 300 seconds. Startup will proceed without waiting any longer
Logger: homeassistant.setup
Source: setup.py:248
First occurred: 19:55:39 (4 occurrences)
Last logged: 19:57:43
- Unable to set up dependencies of ‘history’. Setup failed for dependencies: [‘recorder’]
- Unable to set up dependencies of ‘energy’. Setup failed for dependencies: [‘history’, ‘recorder’]
- Unable to set up dependencies of ‘logbook’. Setup failed for dependencies: [‘recorder’]
- Unable to set up dependencies of ‘default_config’. Setup failed for dependencies: [‘energy’, ‘history’, ‘logbook’]
Logger: homeassistant.setup
Source: setup.py:271
First occurred: 19:55:39 (4 occurrences)
Last logged: 19:57:43
Setup failed for ‘history’: Could not setup dependencies: recorder
Setup failed for ‘energy’: Could not setup dependencies: history, recorder
Setup failed for ‘logbook’: Could not setup dependencies: recorder
Setup failed for ‘default_config’: Could not setup dependencies: energy, history, logbook
That doesn’t sound promising.
I installed 2024.7.2 and removed the workaround. Everything works fine for now.
Hoping it‘s fixed.
After installing update. These logs are after reboot with the workaround reintroduced…
1 Like
I am rebooting again, with auto_purge deleted from config
Now everything is starting, and as expected all missing data is shown in energy dashboard, all at once (all in one bar between 18:00 - 19:00). So, behaviour is as previously reported.
I want auto_purge turned off to avoid purging breaking recording at 4:00 hr… hmm
New reboot, now with auto_purge: false, has succeded…
Do not understand why the 19:55 reboot failed. But fingers crossed is keeps recording now…
Anyway, the original problem is not resolved. After isntalling 2024.7.2 the recorder does still stop recording…
Update: also with auto_purge: false the recorder did not seem to work… but I am not sure and I am not willing to risk further experiments.
I have done a rollback to 2024.7.1
not happy, and would like confirmation by other users that 2024.7.2 is fixing the issue
The database fix seems to have worked for me, but I have to wait and see if it survives the 4:11 purge…so far things are looking good and the logs confirm that the database fix was applied.
You didn’t specify, but what I read about your problem, it is “ISSUE 2” in the first post. The fix for this issue is in the upcoming 2024.8.0.
“ISSUE 1” was fixed by the latest 2024.7.2
Please see the solution post from @petro for more information.
For what it is worth, 2024.7.2 seems to be working now and fixed the issue for me (unless it was something else I did). I assume I had issue 1 from the original post because I don’t run any of the mentioned integrations, but had the issue with middle of the night purge sending CPU high and locking the recorder.
I worked around the issue, by rolling back to 2024.6.4 which is a workaround, as my database would have grown too big without doing this when the assumption as that it would be fixed in 2024.8.
While normally I have the recorder set to keep 4 days of records, I did a manual recorder:purge to keep only 1 day and repacked the DB which brought its size down from 8Gb to about 3GB (in fact the recorder was probably only storing about 3 days of data at this time). I this took a bit less than half an hour. Of course this was all working on 2024.6.4.
Then I did an upgrade to 2024.7.2 and again manually ran a recorder:purge keeping only 1 day which seemed to complete without issues without hanging the recorder. So assume issue is fixed. It finished very quickly because I assume not much is being purged because I only just did it. In a few days when it is running over night and purging more, I will know for sure, but looks good.
Hope that is useful to others.
3 Likes
Thank you for your reply, I will wait for the 2024.8.0 update for now
1 Like
Fixed it for me as well.