Claude finished @Yeraze's task —— View job

PR Review

• Gather context
• Review migration 021 changes
• Review migration 063 for relationship
• Check test coverage
• Post final review

Code Review

Overall: LGTM — the fix is correct and well-reasoned.

What the fix does

Removes channel_database from the DATA_TABLES array in src/server/migrations/021_add_source_id_columns.ts. This breaks the add/drop cycle where:

• Migration 021 (every boot on PG): ALTER TABLE channel_database ADD COLUMN IF NOT EXISTS "sourceId"
• Migration 063 (every boot on PG): ALTER TABLE channel_database DROP COLUMN IF EXISTS "sourceId"

PostgreSQL's dead column tombstones accumulate in pg_attribute and never get reclaimed, eventually hitting the hard 1600-column limit.

Correctness ✅

The fix is correct on all three backends:

• PostgreSQL: Migration 021 no longer adds the column → migration 063's DROP COLUMN IF EXISTS becomes a permanent no-op → tombstone accumulation stops.
• SQLite: Migration 021 uses a try/catch for duplicate column (already idempotent). Migration 063 catches no such column. Both are safe no-ops after the fix.
• MySQL: Migration 021 checks information_schema.COLUMNS before adding — already idempotent. Migration 063 does the same before dropping. Both are harmless no-ops.

Comment quality ✅

The new block comment at the top of 021_add_source_id_columns.ts (lines 11–18) clearly explains:

• Why channel_database is excluded
• The cross-migration dependency (021 ↔ 063)
• The specific PostgreSQL failure mode
• The issue tracker link

This is valuable documentation for future maintainers.

Migration 063 compatibility ✅

Migration 063's DROP COLUMN IF EXISTS (PostgreSQL) and information_schema check (MySQL) mean it's already a safe no-op when the column is absent — no changes needed there.

Impact on affected users ✅

The PR description correctly notes that users who have already hit the limit will recover on restart — migration 021 stops attempting the add, so the 1600-column error won't fire again. Existing tombstones are harmless since no migration adds further columns to channel_database.

Minor observations (non-blocking)

1. No test update needed: The migration test file (src/db/migrations.test.ts) tests migration counts and structure, not the specific table lists inside each migration. No changes required there.

2. SQLite was never affected: The SQLite path catches duplicate column errors, so it was idempotent before this fix too. The fix is still correct to make the behavior consistent and documented.

3. The DATA_TABLES comment at line 7–9 in the file header still accurately lists the 8 remaining tables — channel_database was never listed there since those lines describe the final intended state.

No issues found. The fix is minimal, targeted, well-documented, and correct across all three database backends.