Database migration fails to add new columns on Docker container upgrade

[jorikfon]

Summary

When upgrading a Docker container to a new version while reusing an existing database volume, new columns added in recent versions are missing from the database. This causes PDOException: no such column errors at runtime.

Sentry Evidence

Three related errors from the same server (mikopbx-in-a-docker, release 2026.1.223, PHP 8.4.16):

Sentry #	Error	Missing Column
#27959	no such column: m_LanInterfaces.ipv6_mode	ipv6_mode (added for IPv6 support)
#27960	no such column: m_AsteriskManagerUsers.eventfilter	eventfilter (AMI event filtering)
#27961	no such column: m_Iax.registration_type	registration_type (IAX registration)

All 6 events each, 1 user, triggered via SIPConf::reload() → WorkerModelsEvents.

Expected Behavior

UpdateDatabase::updateDatabaseStructure() runs during boot via SystemLoader::startSystem() and should detect missing columns from model @Column annotations, then add them via ALTER TABLE ADD COLUMN.

Potential Root Cause

In UpdateDatabase::getAddableColumns() (line ~580-621): when extra columns exist in the database that are NOT in the model (e.g., from a previous version or module), the function returns null for core models. This triggers the slow path (full table copy via temp table). During the copy, array_intersect($newColNames, $oldColNames) only transfers data for columns present in both old and new schemas — but the new table structure itself should still have the new columns.

Possible scenarios:

1. Migration errors are silently caught and the old table structure is preserved
2. The migration doesn't run at all in certain Docker upgrade paths
3. A schema comparison mismatch causes the migration to skip the table entirely

Reproduction

1. Run MikoPBX Docker with an older version (pre-IPv6, e.g., 2025.1.x)
2. Create some data (extensions, settings)
3. Upgrade container image to 2026.1.223 while keeping the cf volume
4. Check database: sqlite3 /cf/conf/mikopbx.db ".schema m_LanInterfaces" | grep ipv6_mode

Files to Investigate

• src/Core/System/Upgrade/UpdateDatabase.php — main migration logic
• src/Core/System/Upgrade/UpdateDatabase.php:getAddableColumns() — column addition decision
• src/Core/System/SystemLoader.php:startSystem() — boot sequence calling migration
• src/Core/System/ContainerEntrypoint.php — Docker/LXC boot entry point

Affected Models

• src/Common/Models/LanInterfaces.php — ipv6_mode, ipv6addr, ipv6_subnet, ipv6_gateway, primarydns6, secondarydns6
• src/Common/Models/AsteriskManagerUsers.php — eventfilter
• src/Common/Models/Iax.php — registration_type

[boffart]

не воспроизвеодится при обновлении контейнера с 2024.1.114. на 2026.1.223

[jorikfon]

Another instance of this same root cause appeared in the Sentry pipeline today (release mikopbx@2026.1.223, PHP 8.4.16):

Sentry shortId	Error	Missing column
MIKOPBX-MBV	no such column: cdr_general.src_name	src_name

Trigger path: WorkerCallEvents::start() → selectCDRWorker() → SelectCDR::execute() (src/Core/Workers/Libs/WorkerCallEvents/SelectCDR.php:84) → Phalcon\Mvc\Model::find() over the CallDetailRecords model.

Confirmed that src_name IS declared as a column in src/Common/Models/CallDetailRecordsBase.php (public ?string $src_name = '';) and is referenced from many call sites (CDR list/active calls/active channels APIs, voicemail-sender, transfer rows, etc.) — so the model is correct; the migration just didn't propagate the column to the live cdr_general table on the upgraded instance.

So the Affected Models list in the original issue should also include:

• src/Common/Models/CallDetailRecordsBase.php — src_name (and likely the rest of the recently added CDR columns surfaced via CallDetailRecords::setSource('cdr_general'))

This brings the total to four columns observed missing in the wild from a single root cause; reinforces that UpdateDatabase::updateDatabaseStructure() is the right place to dig.

[boffart]

Sentry-проверка гипотезы «два контейнера разных версий на одной БД»

Поднял по упомянутым shortId события и распределение похожих ошибок в нашем self-hosted Sentry. Кратко.

События из тикета (KTF / KTG / KTH)

• Все три появились в одну секунду 2026-04-14 09:01:39 UTC и затихли в течение часа (last = 10:22:01).
• Источник единственный: один сервер, один пользователь, один релиз mikopbx@2026.1.223, PHP 8.4.16, environment=development.
• count=6 на каждую ошибку, userCount=1. Это похоже на один цикл инициализации/перезапуска контейнера.

Гипотеза о параллельной работе двух docker-инстансов разных версий на общем cf volume технически рабочая — slow path в UpdateDatabase::createUpdateDbTableByAnnotations() действительно безвозвратно дропает колонки, которых нет в модели старого релиза (см. src/Core/System/Upgrade/UpdateDatabase.php:450-492, getAddableColumns() возвращает null для core-моделей при наличии «лишних» колонок). Но прямых следов запуска более раннего релиза на этом сервере в Sentry нет — все события на 2026.1.223.

Что говорит против downgrade-гипотезы как корневой причины

Те же «no such column/table» наблюдаются массово на разных независимых клиентах и серверах:

ShortId	Что отсутствует	count	Кол-во серверов
MIKOPBX-KGY	cdr.src_name	4586	4
MIKOPBX-MBV	cdr_general.src_name	1	1
MIKOPBX-K3G	таблица m_StorageSettings	440	9
MIKOPBX-K3F	таблица m_StorageSettings	77	несколько

Все на mikopbx@2026.1.223 (плюс хвост 2026.1.198-dev). Объяснение «у каждого из 9–10 разных клиентов параллельно стоят два контейнера разных версий с общим volume» нереалистично.

Сопутствующий контекст у клиента из тикета

На том же сервере к моменту 14.04 в Sentry уже были массовые:

• RedisException: MISCONF ... currently not able to persist on disk (тысячи событий с конца марта)
• RedisException: read error on connection to 127.0.0.1:6379
• Phalcon\Storage\Exception: Connection refused
• m_StorageSettings тоже отсутствует.

То есть среда нестабильна (заполненный диск / Redis в MISCONF), и сопутствующие сбои инициализации могли уронить транзакцию миграции.

Почему в Sentry не видно первопричины

В UpdateDatabase.php:497-506 ошибка миграции пишется только в SystemMessages::sysLogMsg(__METHOD__, ..., LOG_ERR) и завершается rollback(). В Sentry это не отправляется — поэтому по запросам UpdateDatabase / updateDatabaseStructure в проекте нет ни одного issue. Мы видим только следствия (PDO «no such column/table») и не видим, на чём упала сама миграция.

Вывод по гипотезе

• Для конкретно KTF/KTG/KTH на одном сервере — downgrade теоретически возможен (код slow path подтверждает сценарий потери «лишних» столбцов), но в Sentry следов другого релиза нет.
• Для массовых инцидентов (KGY, K3G/K3F) гипотеза не подходит — слишком много независимых клиентов.
• Намного вероятнее, что это дефект в slow path UpdateDatabase, чьё исключение глотается в LOG_ERR и не попадает в Sentry.

Что предлагаю сделать дальше

1. Завести отдельный тикет на «UpdateDatabase: send migration failures to Sentry» — продублировать LOG_ERR отправкой Throwable в SentryErrorLogger, чтобы после следующего инцидента увидеть SQL/exception. Это закроет основной слепой пятно.
2. Запросить у пострадавшего клиента /storage/usbdisk1/mikopbx/log/system/messages за 2026-04-14 — там должно быть Error: Failed on create/update table {tableName} от метода createUpdateDbTableByAnnotations.
3. Записывать DB_SCHEMA_VERSION в PbxSettings и при старте блокировать запуск, если DB_SCHEMA_VERSION > CODE_VERSION. Это закроет downgrade-сценарий вне зависимости от того, является ли он причиной этих конкретных событий: текущий slow path реально молча теряет данные «новых» колонок при откате на старый релиз с общим volume.