[BUG] Missing db.commit() after ALTER TABLE in migrations.py — column may not persist on crash

[axisrow]

Description

In src/database/migrations.py, the ALTER TABLE statement that adds the selected_variant column to generation_runs is missing a await db.commit() call immediately after it. Every other similar ALTER TABLE migration in the same function has an explicit commit right after it — this one is the only exception.

Location

File: src/database/migrations.py
Lines: 376–378

Code

# Lines 372–383
if "variants" not in gr_columns:
    await db.execute("ALTER TABLE generation_runs ADD COLUMN variants TEXT")
    await db.commit()  # ✅ present here
if "selected_variant" not in gr_columns:
    await db.execute("ALTER TABLE generation_runs ADD COLUMN selected_variant INTEGER")
    # ❌ await db.commit() is MISSING here
# Ensure publish_times column exists in content_pipelines (PR #125)
cur = await db.execute("PRAGMA table_info(content_pipelines)")

Impact

• If the process crashes or is killed between line 377 and the next commit() (line 383), the selected_variant column is lost — the migration will attempt to add it again on next start, which is benign if there's no data, but can silently hide corruption.
• Databases that experienced an unclean shutdown may differ from those that ran cleanly, making the schema state non-deterministic across deployments.
• Any code that writes to selected_variant (e.g. A/B testing results) will fail on affected databases since aiosqlite operates in isolation_level=None (autocommit), and the unflushed WAL frame may not be checkpointed.

Fix

Add await db.commit() after the ALTER TABLE on line 377:

if "selected_variant" not in gr_columns:
    await db.execute("ALTER TABLE generation_runs ADD COLUMN selected_variant INTEGER")
    await db.commit()  # ✅ add this line

Severity

HIGH — data-integrity regression on unclean shutdown; schema inconsistency across instances.