The database may be in a dirty state. To resolve this, the Alembic CLI can be used from the `src/phoenix/db` directory inside the Phoenix project root. From here, revert any partial migrations and run `alembic stamp` to reset the migration state, then try starting Phoenix again. -- Hello seeing this issue suddenly on the kube. it was working fine till yesterday. pod crashed and app is down.
This error means Phoenix's database migration is incomplete or corrupted ("dirty state"). The recommended fix is to use the Alembic CLI from the src/phoenix/db directory to revert partial migrations and run alembic stamp to reset the migration state, then restart Phoenix. If you can't find src/phoenix/db (e.g., when running from a container), you may need to clone the Phoenix repo locally to access it, or run Alembic from the installed package path. This issue often occurs after an upgrade, downgrade, or if the database is shared or manually altered. If you can't afford to lose data, manual intervention is required; otherwise, deleting the database and starting fresh is the simplest fix. Using a dedicated, fresh database for Phoenix is highly recommended to avoid such conflicts.If you need to run Alembic manually, see the discussion and instructions in these sources. If you need step-by-step guidance for your specific setup (Kubernetes, Docker, etc.), let me know.Sources: - Phoenix migration troubleshooting and Alembic usage - Slack support thread: database dirty state and manual migration
馃挕聽Hint: Mention RunLLM in the thread for followups.
No version update, we are using helm chart deployment. but we created new database in the same schema where phoenix is running. will there be a issue?
hmmm this is using postgres?
yes its right
if it's truly a new database I am confused as to why that would trigger a new mutation, but are you running two applications with separate tables all in the same database?
in which case you can definitely get a conflict
