Colleague's fresh deploy hit psycopg2.errors.UnsafeNewEnumValueUsage
on migration 020:
UPDATE scans SET scan_type='WAZUH'
WHERE scan_type IN ('FULL','SYSCOLLECTOR')
Postgres rejects DML using a newly-added enum value on the same
connection that added it, even after the ADD VALUE transaction
commits — until the connection is closed and reopened. Alembic
runs migrations 019 and 020 on the same connection, so 020 saw
the cached pre-WAZUH enum and refused the UPDATE.
Previous fix attempts (op.execute('COMMIT'), autocommit isolation)
either broke alembic_version tracking or only worked on specific
psycopg2 versions. Rather than chase another connection-level hack
the backfill is dropped:
- Migration 020 is now a no-op. Historic rows in DB stay as FULL /
SYSCOLLECTOR. Migration chain 018 → 019 → 020 → 021 → 022 stays
linear so 021/022 can still run.
- app/routers/scans.py adds _display_scan_type() helper that
collapses 'full' + 'syscollector' + 'manual' → 'wazuh' before
serialising to the API response. Frontend sees the unified label.
- ScanRunSummary.scan_type loosened from ScanType enum to str so
the display-mapped string passes Pydantic validation.
Operators stuck mid-failure (alembic_version=019, restart loop)
recover by pulling this commit + rebuild + restart — migration 020
now succeeds silently and the chain advances past it.
vulncheck
06f1615446