1 commit

Author	SHA1	Message	Date
Ashwin Kumar Sivakumar	dbb02e54cc	fix(db): stop wiping employees table on every migration run, restore phone column ... CRITICAL: 20260402030000_strict_employee_separation.up.sql contained an unconditional DROP TABLE IF EXISTS employees CASCADE followed by a bare CREATE TABLE, written as a one-time schema transformation back when it was authored. The db-migrate tool has no applied-migrations tracking table - it replays every .sql file on every run - which turned that one-time DROP into a destructive operation that wipes every employee account (including admin accounts) on every single migration job run. This is what caused today's "db error while logging in": the phone column (never present in any tracked migration, added out-of-band in production at some point) was gone after the recreate, and every employee row - including the account in use this session - was deleted. Fix: make the table creation a plain idempotent CREATE TABLE IF NOT EXISTS (the standalone-schema transition it performed already happened in production long ago, so the drop was never needed for correctness going forward). Add a proper migration for the phone column so it's tracked instead of relying on an undocumented manual ALTER. Confirmed via kubectl-verified row count (0) and a pre-incident backup (2026-07-18T21:00:03Z, predates the destructive run) that the deleted row is recoverable; restoring it separately as a one-time data fix, not part of this schema migration. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-19 05:40:48 +05:30