Skip to content

fix(backend): fresh install fails -- migration assumes profiles table exists - #116

Closed
arqueon wants to merge 1 commit into
Schroedinger-Hat:mainfrom
arqueon:fix/fresh-install-migration-guard
Closed

arqueon wants to merge 1 commit into
Schroedinger-Hat:mainfrom
arqueon:fix/fresh-install-migration-guard

Conversation

@arqueon

@arqueon arqueon commented Sep 13, 2026

Copy link
Copy Markdown

Summary

On a brand new database, database/migrations/2026-08-06_add_profile_owner.js runs before Strapi creates the profiles table from the content-type schema, so knex.schema.table('profiles', ...) throws relation "profiles" does not exist and the backend crash-loops forever -- docker-compose up never succeeds against an empty database.

The profile content-type schema already declares owner as part of its current shape (src/backend/src/api/profile/content-types/profile/schema.json), so a fresh install doesn't need this migration to do anything -- it only matters for databases created before that field existed.

Fix

Guard the migration with hasTable() so it's a no-op on a fresh install (Strapi creates the table with owner_id already included) and still runs correctly against an existing database that's missing the column.

Test plan

  • Reproduced against a real Postgres instance via docker-compose up on an otherwise-untouched clone (not the sqlite dev default) -- confirmed the crash-loop and the exact error.
  • Applied the fix, recreated the database from scratch, confirmed the backend now boots cleanly with the migration logging "profiles table does not exist yet - skipping (fresh install)".

🤖 Generated with Claude Code

… exists

On a brand new database, database/migrations/2026-08-06_add_profile_owner.js
runs before Strapi creates the `profiles` table from the content-type schema,
so `knex.schema.table('profiles', ...)` throws "relation \"profiles\" does not
exist" and the backend crash-loops forever -- docker-compose up never
succeeds against an empty database.

The profile content-type schema already declares `owner_id` as part of its
current shape, so a fresh install doesn't need this migration to do anything;
it only matters for databases created before that field existed. Guard the
migration with hasTable() so it's a no-op on a fresh install and still runs
correctly against an existing database missing the column.

Reproduced against a real Postgres instance (not the sqlite dev default),
via `docker-compose up` on an otherwise-untouched clone.
@arqueon
arqueon requested a review from TheJoin95 as a code owner September 13, 2026 01:43
@netlify

netlify Bot commented Sep 13, 2026 •

Copy link
Copy Markdown

✅ Deploy Preview for certo canceled.

Name Link
🔨 Latest commit a24c2d8
🔍 Latest deploy log https://app.netlify.com/projects/certo/deploys/6aa5ffd9092f3b00082fe3e4

@Readpato

Copy link
Copy Markdown
Member

Please read through this: https://meatproxy.me/

Not taking time to review this, please avoid opening vibe slop PRs.

Closing.

@Readpato Readpato closed this Sep 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants