[Bug] Migration failed: Table ms3_grid_fields does not exist

[Ibochkarev]

Описание проблемы

При установке MiniShop3 возникает ошибка выполнения миграции. Миграция 20251127000002_seed_customers_grid_config.php пытается вставить данные в таблицу ms3_grid_fields, но таблица ещё не создана.

Стектрейс ошибки:

[MiniShop3] Migration execution failed: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'cc54143_pmk3.ms3_grid_fields' doesn't exist

Шаги воспроизведения

1. Установить MODX 3.x
2. Попытаться установить MiniShop3 через пакетный менеджер
3. Процесс установки прерывается на выполнении миграций

Окружение

• MiniShop3: 1.10.1-beta1
• MODX: 3.x
• PHP: 8.x

Дополнительный контекст

Проблема встречается при частичной или повторной установке.

Источник: https://modx.pro/components/23253#comment-146592

[biz87]

PR #271 закрывает каскадное падение seed-миграций — теперь при отсутствии ms3_grid_fields миграции выходят no-op с явным сообщением в output вместо SQLSTATE 42S02. Это обход симптома, но не root cause.

Root cause всё ещё открыт: на сервере пользователя msGridField не создаётся в 20251020000000_initial_schema. Без этой таблицы grid configs Vue-админки фактически не будут работать (пустые гриды) — defensive checks дают чистое логирование, но функционал теряется.

Гипотезы (без воспроизведения сказать точно нельзя)

1. Конфликт двух TIMESTAMP DEFAULT CURRENT_TIMESTAMP в одной таблице. В схеме msGridField есть created_at (DEFAULT CURRENT_TIMESTAMP) + updated_at (ON UPDATE CURRENT_TIMESTAMP). До MySQL 5.6.5 такая комбинация запрещена. MySQL 5.7 это поддерживает, но при explicit_defaults_for_timestamp = OFF (старый дефолт) поведение незакономерно.

2. Скрытый фейл xPDO Manager::createObjectContainer(). initial_schema в случае фейла создания таблицы пишет Failed to create table в output и идёт дальше — без throw. Если хостинг подавляет вывод миграций, ошибка незаметна, а seed-миграции потом падают на отсутствующей таблице. Стоит дополнить initial_schema, чтобы он throw при провале — Phinx тогда остановится и покажет точную миграцию-виновника.

3. 'phptype' => 'json' колонки config на MySQL 5.7 транслируется xPDO в TEXT, должно работать. Маловероятно.

4. MySQL версия из багрепорта — 5.7, но возможно у Timeweb это древняя точечная версия с особенностями strict_mode/sql_mode. В частности NO_ZERO_DATE, NO_ZERO_IN_DATE могут конфликтовать с TIMESTAMP NOT NULL без явного DEFAULT.

План воспроизведения

1. Поднять MySQL 5.7 локально (Docker: docker run -d -p 3307:3306 -e MYSQL_ROOT_PASSWORD=test mysql:5.7).
2. Создать чистый MODX 3.x на этой БД.
3. Запустить установку MS3 → посмотреть полный output initial_schema (через CLI Phinx, не через пакетный менеджер, чтобы output не глотался).
4. Если msGridField зафейлил — собрать SQL, который пытается выполнить xPDO Manager (через ms3_log_level = debug или прямой dump), и попробовать выполнить руками. Тогда станет видна точная DB-ошибка.

Что точно НЕ root cause

Скриншот phpMyAdmin от пользователя с предупреждением «key, precision, null, default являются зарезервированными словами MySQL» — это диагностический warning phpMyAdmin при ручном CREATE TABLE через UI-форму. Эти слова встречаются в xPDO fieldMeta как атрибуты колонок (null, precision, default), а не как имена. При нажатии OK таблица создаётся. К ошибке initial_schema не относится.

Что предлагаю

• Issue не закрывать после мержа PR fix(migrations): defensive checks for ms3_grid_fields table #271 — это только обход.
• Метка «needs reproduction» — без MySQL 5.7 локально root cause не найти.
• Хорошая идея — улучшить initial_schema, чтобы он throw при фейле создания таблицы. Тогда в следующем релизе пользователи будут видеть точную причину, а не «Table doesn't exist» на 12-й миграции.