error: error returned from database: (code: 5) database is locked: (code: 5) database is locked about serene-aur

[mariuszste]

and builds seem to be failing as well because of it [2024-05-13T12:37:45Z ERROR serene::build] build run for package failed extremely fatally: error returned from database: (code: 5) database is locked: (code: 5) database is locked

[VirtCode]

I thought that the server is using the database correctly, with a database pool provided by the library I'm using (sqlx). So I did some research and came across what seems to be the same issue on the repo of the library: launchbadge/sqlx#451

So the problem seems to be caused by disk being too slow as far as I can tell, or something related to that. There are a couple of different fixes we could try. Sadly, I can't reproduce the issue on my end, I currently don't have any slow-enough hard drives lying around, so you'll have to test them.

The first thing we can try is whether setting the SQLite journaling mode to WAL is enough. I've pushed a fix onto main which enables that, as it should be enabled anyways for all connections as it offers more performance. So it would be great if you could pull the new image and test whether that already fixes the issues on your setup.

If that doesn't work (which may very well be as adding and building packages are mostly write operations, which are still not possible to run in parallel even with WAL), we'll probably have to resort to something more drastic, limiting the amount of connections to 1. That would then probably do the trick, but is not really desirable as it may impact performance quite a bit.

[dumbasPL]

I threw a bunch of packages at it again and it seems to be fixed or at least not as bad (0 failures so far and 0 jobs stuck on working). Adding WAL was a good idea either way.

In theory launchbadge/sqlx#459 should fix this completely without affecting read performance but there doesn't seem to be any interest in implementing it any time soon.

[VirtCode]

Okay that's great, I'll close this then for the time being.
If the error appears again, please reopen this issue, and we can consider using two pools or simply limit the connections to 1.