Migrazione 015 si rompe su DB creati da create_all (uq_users_api_key inesistente) #71
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
FILE: src/backend/migrations/versions/015_api_key_hash.py:39-42 — batch.drop_index("ix_users_api_key") poi batch.drop_constraint("uq_users_api_key").
COSA SI ROMPE: un DB nato da Base.metadata.create_all (non da 000_base_schema) ha su users.api_key un solo UNIQUE KEY ix_users_api_key, nessun uq_users_api_key. drop_constraint → MySQL 1091 "Can t DROP uq_users_api_key". MySQL non ha DDL transazionale: api_keys resta creata e l indice tolto, alembic_version resta 014; ogni riavvio rifà 015 e muore su 1050 "Table api_keys already exists". Server in restart loop.
INPUT: demo tieflow.tielogic.xyz, aggiornamento da
e0f32fe(alembic 010) a82ad885il 12/10/2026. VERIFICATO: show create table users del backup pre-aggiornamento → solo UNIQUE KEY ix_users_api_key.RIPARATO A MANO sulla demo: ALTER TABLE users DROP COLUMN api_key; alembic_version=015_api_key_hash; riavvio → 016-019 applicate, DB a 019.
RISCHIO: l installazione Tràfilo, se il DB è nato da create_all o dal setup /api/setup/init-db.
FIX ATTESO: 015 idempotente — ispezionare indici/vincoli presenti (sa.inspect) e togliere solo quelli che esistono; create_table api_keys solo se manca. Verificare 000-019 contro un DB creato da create_all (test di migrazione).
⚡ jeeg — preso in carico 2026-10-15T07:21:11Z
ramo:
lavoro/jeeg· capacità: docker, gpu, systemdSoluzione
ESITO: fatto
COSA: 015_api_key_hash.upgrade() idempotente: ispeziona il DB (sa.inspect) e crea api_keys e i suoi indici solo se mancano, toglie ix_users_api_key / uq_users_api_key solo se esistono, salta users se api_key è già sparita. downgrade() invariato.
CAUSA: ORM pre-#41 (
e0f32feuser.py:35) api_key unique=True,index=True → create_all crea solo UNIQUE ix_users_api_key; 015 cercava anche uq_users_api_key.COMMIT:
74fe566(fix + 2 test), merge5bf374asu V3.0.0.FILE: src/backend/migrations/versions/015_api_key_hash.py:24; src/backend/tests/test_migrations.py — test_015_on_create_all_schema, test_015_resumes_after_partial_run.
PROVA: pytest src/backend/tests → 537 passed; test nuovi falliscono col codice vecchio (2 failed).
PROVA MySQL 8.0 (docker, jeeg): codice vecchio su schema create_all → 1091 Can't DROP uq_users_api_key, fermo a 014 (riprodotto). Codice nuovo: create_all, 015 a metà (api_keys già creata, ix tolto), schema da 000 → tutti e tre a 019_station_vision_worker, users.api_key assente, api_keys con i due indici.
MANCA: Tràfilo prende il fix col prossimo deploy di V3.0.0; la demo tieflow era già riparata a mano.