Major data loss -- server doesn't appear to write data to disk properly

[exscape]

• I am on the latest ActivityWatch version.
• I have searched the issues of this repo and believe that this is not a duplicate.

• OS name and version: Windows 11, 22H2 (22621.1848)
• ActivityWatch version: 0.12.2

Describe the bug

After a power outage at night, while the computer was in sleep/standby, all data for the past few days was lost. I started using ActivityWatch on June 10th and now have data for the these dates: 10, 11, 12, 13, 18.

To Reproduce

1. Gather some data
2. Kill aw-server-rust.exe
3. Restart aw-server-rust.exe

All data gathered since the last graceful exit is lost when I do this, as mentioned above even days worth of data.

However, making things worse, I could reproduce this while testing, but not every time. I'm not sure what the difference between tries is. I'm also not sure if data is written properly but is corrupted, or simply not written at all.

Expected behavior

Data should be written to disk regularly, perhaps every 5 minutes or so, and persist even if power is lost/the server crashes etc.

[exscape]

Um, the data is now there. I have no idea what's going on, but the server has been running since 08:52:07 which is just before I submitted this bug report, and it didn't work when I submitted.

I am 100% sure it was missing (in the web UI) between multiple server restarts. The small bars that shows total activity per day were at height 0 for those days, and when viewing the daily activity, "No data" was all that was shown (just as it looks if you view a future date).

Perhaps this is rather a webui issue?

[exscape]

This happened again just now.

Every day from the one on the far left to and including today have 8+ hours of activity in them, that for whatever reason doesn't show up now.
I'm expecting it to show up again sooner or later since it did last time, but at the moment it appears entirely gone.

Interestingly, the server has been running since yesterday and it worked fine a few hours ago, so it has nothing to do with the server stopping/crashing as I first thought.

Screenshot taken just now, 2023-07-01 21:20.

[TimeToBuildBob]

This is likely caused by a commit failure during unclean shutdown — the database worker panics on commit errors, which can leave the WAL in an inconsistent state. PR #572 addresses the root cause by replacing the panic with graceful error handling and automatic retry.