From e4507ca8a020c945c4f44dca853ec31ecb90d6c5 Mon Sep 17 00:00:00 2001 From: Anthony GAEREMYNCK <1@anthony.sh> Date: Fri, 31 Jul 2026 02:05:37 +0200 Subject: [PATCH] Fix broken migration fallback in CLAUDE.md; add defensive null guards The documented shadow-database-free fallback for generating migration SQL (--from-migrations ... --to-schema-datamodel ...) was never actually tested and fails for the same P3014 reason `migrate dev` does, since --from-migrations also requires --shadow-database-url internally. Verified against the local dev DB that --from-schema-datasource (live introspection, no shadow DB) diffed against --to-schema-datamodel (static file read) works in both the no-op case and a real ADD COLUMN case, and documented that instead. Also corrected the inaccurate claim that this matched Task 3's approach (Task 3 used --from-empty) and moved the suggested SQL output path out of the repo root into the OS temp directory. Also brings markFailed's errorMessage/errorLog params in line with markDone's existing ?? null guard, and adds orderBy to findExpiredJobs to match findPendingJobs, for consistency. Co-Authored-By: Claude Sonnet 5 --- CLAUDE.md | 9 ++++++--- src/jobs/jobRepository.js | 3 ++- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index ff204b8..28b1f2e 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -69,16 +69,19 @@ Fall back to Grep/Glob/Read **only** when the graph doesn't cover what you need. User was denied access on the database `prisma_migrate_shadow_db_...` ``` No migration folder is created when it fails this way (it errors before writing anything), so nothing needs cleaning up afterward. Do not use `migrate dev` in this project until `convert_user`'s privileges change. -- To create a new migration locally after editing `prisma/schema.prisma`, use the shadow-database-free fallback instead (the same pattern Task 3 used for the `0_init` baseline): +- To create a new migration locally after editing `prisma/schema.prisma`, use the shadow-database-free fallback instead. Note this is **not** the same pattern Task 3 used for the `0_init` baseline — Task 3 used `--from-empty` (diffing against a blank schema), which is a different mode that also happens not to need a shadow database, but is not applicable here since the local DB is not empty. The verified fallback for an already-baselined DB is `--from-schema-datasource` (introspects the live DB's actual current structure — a real DB connection, but not a shadow database) diffed against `--to-schema-datamodel` (reads the target state straight from a schema file, no DB connection at all): ``` DB_HOST=127.0.0.1 DB_USER=convert_user DB_PASSWORD=change_me DB_NAME=file_converter STORAGE_DIR=./storage \ DATABASE_URL=$(node scripts/printDatabaseUrl.js) npx prisma migrate diff \ - --from-migrations prisma/migrations --to-schema-datamodel prisma/schema.prisma --script > migration.sql + --from-schema-datasource prisma/schema.prisma --to-schema-datamodel prisma/schema.prisma --script > /tmp/migration.sql ``` - Review `migration.sql`, then manually create the next `prisma/migrations/_/migration.sql` folder with that content, and mark it applied without executing it (since you'll apply it for real via `migrate deploy` or by hand): + This was verified twice against the local dev DB: with `prisma/schema.prisma` unchanged it printed `-- This is an empty migration.` (no shadow database requested, no error); with a throwaway copy of the schema (an extra `notes String? @db.Text` field on `ConversionJob`, passed as `--to-schema-datamodel `) it printed a correct `ALTER TABLE conversion_jobs ADD COLUMN notes TEXT NULL;` — again with no shadow database involved. The earlier documented fallback here (`--from-migrations prisma/migrations`) was wrong: `--from-migrations` internally requires `--shadow-database-url` too, so it fails for the same P3014 reason `migrate dev` does; it was never actually tested before being written down. + + Write the generated SQL to a path under the OS temp directory (e.g. `/tmp/migration.sql`), never to a file in the repo (an untracked `migration.sql` in the repo root is easy to accidentally commit). Review it, then manually create the next `prisma/migrations/_/migration.sql` folder with that content, and mark it applied without executing it (since you'll apply it for real via `migrate deploy` or by hand): ``` DATABASE_URL=$(node scripts/printDatabaseUrl.js) npx prisma migrate resolve --applied _ ``` + Delete the temp SQL file once it's been copied into the migration folder. - To apply pending migrations in production: with the real `DB_*` values loaded from `.env`, run `DATABASE_URL=$(node scripts/printDatabaseUrl.js) npx prisma migrate deploy` before starting the app. - **ONE-TIME step, required before the very first `migrate deploy` against any environment whose `conversion_jobs` table predates Prisma** (this includes o2switch production, which still has the table created by hand from the now-deleted `db/schema.sql`, but no `_prisma_migrations` tracking table): do **not** run `migrate deploy` first. Instead, baseline that environment exactly like Task 3 did locally: ``` diff --git a/src/jobs/jobRepository.js b/src/jobs/jobRepository.js index 49bc13d..5922c9c 100644 --- a/src/jobs/jobRepository.js +++ b/src/jobs/jobRepository.js @@ -67,7 +67,7 @@ export async function markDone(prisma, id, { outputPath, outputMimeType, outputS export async function markFailed(prisma, id, { errorMessage, errorLog }) { await prisma.conversionJob.update({ where: { id }, - data: { status: 'failed', errorMessage, errorLog }, + data: { status: 'failed', errorMessage: errorMessage ?? null, errorLog: errorLog ?? null }, }); } @@ -83,6 +83,7 @@ export async function findPendingJobs(prisma, limit) { export async function findExpiredJobs(prisma) { return prisma.conversionJob.findMany({ where: { expiresAt: { lt: new Date() }, cleanedAt: null }, + orderBy: { createdAt: 'asc' }, select: jobSelect, }); }