# 1.6.8 — release notes

## Bug fixes

- **(#3747) Restored login for databases created before v1.4.0.**
  Users whose encrypted user database was created before 2026-03-25
  (v1.4.0, when Alembic migrations were introduced) could not log in
  after upgrading: their databases lacked the `alembic_version` row, and
  the migration runner attempted to apply migrations from scratch against
  a legacy column shape. Migration `0007`'s index backfill then failed on
  missing columns (e.g. `settings.category`), leaving the database in a
  corrupted intermediate state.

  This release detects pre-Alembic databases on first launch, stamps them
  at the correct baseline (revision `0001`), and lets the remaining
  migrations apply cleanly. Look for the `BUG-3747:` log line at startup
  to confirm the recovery path engaged.

  Affected users just need to update to `1.6.8` (or `:latest` / `:1.6`)
  and restart — the recovery is automatic on the next launch.

  ### Hardening

  - `stamp_database()` is now race-tolerant: concurrent stampers (e.g. two
    same-user logins arriving simultaneously) no longer trigger
    `OperationalError` / `IntegrityError` on the duplicate
    `alembic_version` insert. The race-tolerance is narrowly scoped to
    `alembic_version`-related errors, so disk-full / corruption / unrelated
    `SQLITE_BUSY` errors continue to propagate.
  - `run_migrations()` refuses to operate on what looks like an auth-DB
    shape (only `users` table, optionally with `alembic_version`) — defense
    in depth against accidentally routing the auth engine through the
    user-DB migration runner.