we've been running into the following a lot in the past week
phoenix.exceptions.PhoenixMigrationError:
2024-09-23 10:57:07.877 PDT
Unable to migrate configured Phoenix DB. Original error:
2024-09-23 10:57:07.877 PDT
CommandError: Can't locate revision identified by '3be8647b87d8'
2024-09-23 10:57:07.877 PDT
The above exception was the direct cause of the following exception:
2024-09-23 10:57:07.877 PDT
Traceback (most recent call last): File "<frozen runpy>", line 198, in _run_module_as_main File "<frozen runpy>", line 88, in _run_code File "/phoenix/env/phoenix/server/main.py", line 233, in <module> app = create_app(
2024-09-23 10:57:07.877 PDT
^^^^^^^^^^^
2024-09-23 10:57:07.877 PDT
File "/phoenix/env/phoenix/server/app.py", line 340, in create_app
2024-09-23 10:57:07.878 PDT
raise PhoenixMigrationError(msg) from e
2024-09-23 10:57:07.878 PDT
phoenix.exceptions.PhoenixMigrationError:
2024-09-23 10:57:07.878 PDT
鈿狅笍鈿狅笍 Phoenix failed to migrate the database to the latest version. 鈿狅笍鈿狅笍
2024-09-23 10:57:07.878 PDT
The database may be in a dirty state. To resolve this, the Alembic CLI can be used
2024-09-23 10:57:07.878 PDT
from the `src/phoenix/db` directory inside the Phoenix project root. From here,
2024-09-23 10:57:07.878 PDT
revert any partial migrations and run `alembic stamp` to reset the migration state,
2024-09-23 10:57:07.878 PDT
then try starting Phoenix again.
Phoenix is deployed as a sidecar in Cloudrun, and so running alembic stamp from the container would be.. challenging. We've had to rollback our database as a workaround but would like to avoid doing this again due to data loss. What would be the best course of action here? It would be nice if alembic stamp ran automatically without user invention
