Found during a fresh-install walkthrough of 2.5.0-rc.5.
What happens
On the very first start against an empty database, the entrypoint tries to roll back "known problematic" migrations before any migration has run. Since there is no _prisma_migrations table yet, this cannot succeed, and it fails loudly — twice:
[entrypoint] Found 84 migration(s) to apply
[entrypoint] Checking for failed migrations...
[entrypoint] ⚠️ Migration status check failed (exit code: 1)
[entrypoint] This may indicate failed migrations - trying to resolve known problematic ones...
Error: Invariant violation: called markMigrationRolledBack on a database without migrations table.
0: schema_core::state::MarkMigrationRolledBack
with migration_name="20250120000000_add_training_config"
at schema-engine/core/src/state.rs:483
Error: Invariant violation: called markMigrationRolledBack on a database without migrations table.
0: schema_core::state::MarkMigrationRolledBack
with migration_name="20251220000000_add_training_config"
at schema-engine/core/src/state.rs:483
[entrypoint] Continuing with migrations...
Everything then works: all 84 migrations apply, seeds run, the instance comes up healthy.
Why it matters
This is the first output a self-hoster ever sees from the product, and docker compose logs -f on first start is exactly what a careful one does. Two red Error: blocks with a Rust stack frame, before anything has succeeded, read as a broken install. It is harmless, which is precisely why it should not look alarming.
Steps to reproduce
docker compose up against a brand-new volume.docker logs <app> — the two blocks appear before the first Applying migration.
What should happen
Skip the repair step when there is no migrations table (a fresh database has nothing to repair), or run it quietly and only report if it finds something. The ⚠️ Migration status check failed line is itself expected on a fresh database and could say so.
Version
2.5.0-rc.5, empty postgis/postgis:15-3.4 volume
Found during a fresh-install walkthrough of 2.5.0-rc.5.
What happens
On the very first start against an empty database, the entrypoint tries to roll back "known problematic" migrations before any migration has run. Since there is no
_prisma_migrationstable yet, this cannot succeed, and it fails loudly — twice:Everything then works: all 84 migrations apply, seeds run, the instance comes up healthy.
Why it matters
This is the first output a self-hoster ever sees from the product, and
docker compose logs -fon first start is exactly what a careful one does. Two redError:blocks with a Rust stack frame, before anything has succeeded, read as a broken install. It is harmless, which is precisely why it should not look alarming.Steps to reproduce
docker compose upagainst a brand-new volume.docker logs <app>— the two blocks appear before the firstApplying migration.What should happen
Skip the repair step when there is no migrations table (a fresh database has nothing to repair), or run it quietly and only report if it finds something. The
⚠️ Migration status check failedline is itself expected on a fresh database and could say so.Version
2.5.0-rc.5, empty postgis/postgis:15-3.4 volume