s.esmaeiliandClaude Opus 5
a12fb0450e
The folder-discovery fix in the previous commit surfaced a second problem. Databases migrated BEFORE that fix recorded the baseline under the name of the hand-added flat duplicate that used to sit beside it (prisma/migrations/0001_init.sql). Once the runner started discovering the real folder (20260910113720_first), it saw a name it had never recorded and tried to apply the baseline again — against a database that already had it: Raw query failed. Code: 42710. ERROR: type "AdminRole" already exists The two files are identical SQL (verified byte-for-byte after normalising line endings; they differ only by one trailing blank line), so the recorded legacy name genuinely means that migration is applied. A LEGACY_NAME_ALIASES map now treats '0001_init.sql' as an already-applied marker for '20260910113720_first', so upgrading an existing database is a no-op instead of a crash. Verified against the local dev database this actually broke on (postgresql://localhost:5432/gold_banking, which had recorded only the old flat name): 'npm run dev' in apps/api now logs 'No pending migrations' and 'Nest application successfully started' instead of dying. That database's tracking table was also reconciled to record both real migration names, and it was confirmed to already contain both migrations' schema (AdminRole, City.percent, user_type, CustomerKind all present) — nothing was re-run against it. The dockerised database is unaffected: it already records the real names, so the alias is inert there. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>