Alembic hardcodes alembic_version.version_num to VARCHAR(32) in
DefaultImpl.version_table_impl, and version_table_column_width is NOT a
real kwarg that context.configure() honors — it's silently ignored, so
the env.py change alone was never going to take effect on a fresh DB.
Our descriptive revision ids exceed 32 chars (e.g. 003_make_users_hashed_
password_nullable = 39, common 002_add_normalized_products_upc_variants_
index = 46), so the 003 / common 002 stamp fails with StringDataRight-
Truncation, the whole chain rolls back, and the column is recreated at
VARCHAR(32) on the next attempt.
Fix:
- api/alembic/versions/001_encrypt_session_data.py: insert ALTER TABLE
alembic_version ALTER COLUMN version_num TYPE VARCHAR(128) as the very
first statement of upgrade(), before any early-return path. Idempotent
when the column is already wider (e.g. the CAR-1298 one-shot Job).
- common/alembic/versions/001_add_email_inbound_token.py: same defensive
ALTER as the first statement of upgrade() (common is a library, not
deployed, but the 46-char 002 id would have hit the same trap).
- api/alembic/env.py: remove the phantom version_table_column_width=128
kwarg from both context.configure() call sites — it was a no-op and
misled the original investigation.
No downgrade() changes: a matching narrowing could truncate.
Refs CAR-1302 (durable root fix), CAR-1298 (prod workaround this
replaces). Verified against a fresh PostgreSQL — all 9 api migrations
upgrade head with no StringDataRightTruncation, and common 001/002 stamp
the 46-char id cleanly. Cluster has pgcrypto enabled by the operator.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Barcode Betty
Pawla Abdul