aw-server 0.13.2 startup loop on corrupt SQLite DB; .recover restores data

Author: elpinguinofrioCreated Aug 31, 2026Updated Aug 31, 2026

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:

bash
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.

Source: ActivityWatch/activitywatch