Environment
- ActivityWatch /
aw-server: 0.13.2
- macOS 15.7.3 (24G419), arm64
- Storage backend: Peewee / SQLite
Observed behavior
aw-server repeatedly exited during startup with:
sqlite3.DatabaseError: database disk image is malformed
peewee.DatabaseError: database disk image is malformed
The bundled app's restart action produced the same startup failure. The database file was last modified on July 25, and the first retained log containing this error was July 27. I do not know what originally caused the corruption.
An independent read-only SQLite check reproduced it:
$ sqlite3 -readonly peewee-sqlite.v2.db 'PRAGMA quick_check;'
Error: in prepare, database disk image is malformed (11)
There was no -wal, -journal, or backup file beside the database.
Recovery result
After preserving the original file, the standard SQLite recovery path succeeded:
sqlite3 corrupt.db '.recover' | sqlite3 recovered.db
sqlite3 -readonly recovered.db 'PRAGMA integrity_check;'
# ok
Recovered data:
- 2 buckets
- 148,065 events
- Event range: 2026-01-30 through 2026-07-25
- 0 invalid event JSON rows
- 0 orphaned event rows
After replacing the corrupt database with the recovered one, the actual bundled aw-server started successfully. Both /api/0/info and /api/0/buckets/ returned HTTP 200, and the full ActivityWatch app then launched normally.
Suggested improvement
Could aw-server or aw-qt preserve the corrupt file and offer an automatic recovery/backup fallback (or at least show actionable recovery instructions) instead of remaining in a restart loop? This appears related to the older closed issue #271, but reproduces on 0.13.2 and the SQLite .recover path preserved the data successfully.
Environment
aw-server: 0.13.2Observed behavior
aw-serverrepeatedly exited during startup with:The bundled app's restart action produced the same startup failure. The database file was last modified on July 25, and the first retained log containing this error was July 27. I do not know what originally caused the corruption.
An independent read-only SQLite check reproduced it:
There was no
-wal,-journal, or backup file beside the database.Recovery result
After preserving the original file, the standard SQLite recovery path succeeded:
Recovered data:
After replacing the corrupt database with the recovered one, the actual bundled
aw-serverstarted successfully. Both/api/0/infoand/api/0/buckets/returned HTTP 200, and the full ActivityWatch app then launched normally.Suggested improvement
Could
aw-serveroraw-qtpreserve the corrupt file and offer an automatic recovery/backup fallback (or at least show actionable recovery instructions) instead of remaining in a restart loop? This appears related to the older closed issue #271, but reproduces on 0.13.2 and the SQLite.recoverpath preserved the data successfully.