Two branches have now failed at startup with a raw Alembic traceback when run against the shared database:
alembic.script.revision.ResolutionError: No such revision or branch 'a7b9c1d3e5f7'
Cause: OPAL_DATABASE_URL (commonly exported in the shell) points the checkout at a database whose alembic_version head was written by a different/newer branch. Any branch whose migrations/versions/ doesn't contain that revision crashes in init_database → _run_alembic_upgrade with the traceback above. The reverse case is worse: a branch carrying a newer migration will silently upgrade the shared DB and strand every other checkout.
Proposed guard, in _run_alembic_upgrade (src/opal/db/base.py): before invoking command.upgrade, read the DB's current revision and check it against the script directory. On mismatch, exit with a short actionable error instead of the traceback — naming (1) the resolved database path and which setting/env var selected it, (2) the offending revision, and (3) the remedies: run from a branch that contains the revision (rebase onto devel), or point at a throwaway DB (env -u OPAL_DATABASE_URL OPAL_DATA_DIR=$(mktemp -d) uv run opal init && opal seed && opal serve).
Optionally: a --allow-upgrade style acknowledgement before migrating a DB whose path is outside the checkout's own data dir, to prevent the silent cross-branch upgrade case.
🤖 Generated with Claude Code
Two branches have now failed at startup with a raw Alembic traceback when run against the shared database:
Cause:
OPAL_DATABASE_URL(commonly exported in the shell) points the checkout at a database whosealembic_versionhead was written by a different/newer branch. Any branch whosemigrations/versions/doesn't contain that revision crashes ininit_database→_run_alembic_upgradewith the traceback above. The reverse case is worse: a branch carrying a newer migration will silently upgrade the shared DB and strand every other checkout.Proposed guard, in
_run_alembic_upgrade(src/opal/db/base.py): before invokingcommand.upgrade, read the DB's current revision and check it against the script directory. On mismatch, exit with a short actionable error instead of the traceback — naming (1) the resolved database path and which setting/env var selected it, (2) the offending revision, and (3) the remedies: run from a branch that contains the revision (rebase onto devel), or point at a throwaway DB (env -u OPAL_DATABASE_URL OPAL_DATA_DIR=$(mktemp -d) uv run opal init && opal seed && opal serve).Optionally: a
--allow-upgradestyle acknowledgement before migrating a DB whose path is outside the checkout's own data dir, to prevent the silent cross-branch upgrade case.🤖 Generated with Claude Code