The board would not start against any existing database, so Caddy had
nothing to proxy to and answered 502. Reproduced by rebuilding the
server's database from the previous schema and starting the app the way
gunicorn does.
The cause is one line of schema.sql:
CREATE INDEX IF NOT EXISTS attachments_message ON attachments(message_id)
IF NOT EXISTS guards the index NAME, not the column. On a database whose
attachments table predates message_id, executescript dies with "no such
column" — before any migration could add it, because init_db runs the
schema first by design. Every index on a column a migration introduces
belongs in the migration, after the column exists. It now lives there,
outside the rebuild branch so a freshly created database gets it too.
Second bug, latent and worse: the rebuild set PRAGMA foreign_keys = OFF
inside the transaction, where it is documented to be a no-op. It looked
applied and did nothing. Moved outside BEGIN. The test fixture had been
passing for the wrong reason — it left foreign keys at SQLite's default,
which is off — and now turns them on as connect() does.
Both are the same mistake in different clothes: the tests exercised
migrations.apply directly, so nothing ever ran init_db against a
database from before the change. That test exists now. It builds the
previous schema, inserts the row the server actually has, starts the
app, and asserts the photo survived and a restart is a no-op. Verified
by reinstating the bad line and watching it fail with the same error the
server gave.
230 tests.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn
73ad25a15a