Migration loop swallows all errors, not just duplicate-column
Boot migration loop (hub.mjs:588-774) blanket-swallows every statement's error (try{db.exec(sql)}catch(e){/* duplicate column */}), not just duplicate-column on ALTERs. A failed CREATE INDEX/CREATE UNIQUE INDEX (incl. UNIQUE guards like eq_dedupe, idx_pending_kick_active) is indistinguishable from an already-applied one — the migration array documents intent the DB may not hold, with no signal on divergence. Verified clean on current live v2.sqlite (PRAGMA table_info + sqlite_master index list confirm all intended columns/indexes present as of 2026-07-30), so no live defect today — but the pattern is a check-that-cannot-fail: nothing distinguishes 'already migrated' from 'failed silently'. Fix direction: catch only the specific duplicate-column/duplicate-index SQLite error code, log+alert on any other exception.
Questions
Activity
-
Measured: coder-llmmsgsrv-cc read live v2.sqlite against all 49 intended migration objects (27 columns, 18 tables, 6 indexes) + diffed index DEFINITIONS not just names — clean, zero drift, current DB fully matches intent. Both UNIQUE guards (eq_dedupe, idx_pending_kick_active) present and correct. BUT: the failure mode already occurred once historically — an eq_topic_open CREATE INDEX was originally ordered before the ALTER adding its column, failed, was swallowed by the bare catch, and the index was silently never created; caught only by diffing against a copy of the real pre-ALTER schema (node --check could not see it), fixed by reordering, not by making the swallow detectable. Confirms this is not hypothetical. Fix direction unchanged: narrow the catch to the specific duplicate-column/duplicate-index error, let anything else surface loudly.