mirror of
https://github.com/pyMC-dev/pyMC_Repeater.git
synced 2026-10-31 04:01:59 +01:00
Perry MosbacherandClaude Opus 5
bd0c340856
`SQLiteHandler.__init__` runs `_init_database()` and then `_run_migrations()`. `_init_database` created `idx_packets_upstream_time`, which spans `upstream_hash` and `upstream_hash_size` -- columns that, on a database predating migration 13, only appear once `add_upstream_hash_to_packets` has added them in the *later* migration step. Fresh installs were fine, because the `CREATE TABLE` carries both columns. Any existing database raised `no such column: upstream_hash` part-way through `_init_database`, which caught and logged it. Every statement after the failing index was therefore skipped -- including the `room_messages` and `room_client_sync` tables -- and the daemon started with a partially-created schema while reporting itself healthy: service active, radio initialised, companions serving, HTTP up, and no packets recorded. The `add_upstream_hash_to_packets` migration already creates this index, right after adding the columns it depends on, so the copy in `_init_database` was redundant as well as too early. Remove it and leave the index to the migration that owns those columns. All three paths still end up with it: a fresh database gets the columns from `CREATE TABLE` and the index when the migration runs, an un-migrated database gets both from the migration, and an already-migrated one kept the index from its earlier run. Observed on a Raspberry Pi 4 upgrading a ~13 MB production database from 1.1.1; the repeater was off-air for four minutes before the cause was found. It self-heals on a second start, because the migration still runs after the failed init, which makes it easy to misread as harmless. `tests/test_sqlite_upgrade_existing_db.py` builds a database with the pre-migration-13 schema and asserts `_init_database` runs to completion, keyed on tables created after the old failure point. Asserting only on the upstream columns is not sufficient -- the migration adds those either way. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>